home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-chang-iimc-proxy-03.txt
< prev
next >
Wrap
Text File
|
1993-08-09
|
187KB
|
4,333 lines
INTERNET DRAFT Expires February 5, 1994
ISO/CCITT and Internet Management Coexistence (IIMC):
ISO/CCITT to Internet Management Proxy
(IIMCPROXY)
Draft 3
August 5, 1993
April Chang (Editor)
NetLabs, Inc.
4920 El Camino Real
Los Altos, CA 94022
april@netlabs.com
Status of this Memo
This document provides information to the network and systems
management community. This document is intended as a
contribution to ongoing work in the area of multi-protocol
management coexistence and interworking. This document is part
of a package; see also [IIMCOMIBTRANS] [IIMCIMIBTRANS]
[IIMCMIB-II] and [IIMCSEC]. Distribution of this document is
unlimited. Comments should be sent to the Network Management
Forum IIMC working group (iimc@thumper.bellcore.com).
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other
than as a "working draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on ds.internic.net,
nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au to learn the
current status of any Internet Draft.
Chang Expires February 5, 1994 Page i
Draft ISO/CCITT to Internet Management Proxy 8/5/93
Abstract
This document is intended to facilitate the use of the
ISO/CCITT Common Management Information Protocol (CMIP) for
integrated management of networks via proxy management of
TCP/IP networks that are managed using Simple Network
Management Protocol (SNMP). This document describes an
ISO/CCITT to Internet "proxy" which allows interworking between
CMIP-based managers and SNMP-based agents. The proxy emulates
CMIS service requests by mapping between corresponding
ISO/CCITT GDMO and Internet MIB definitions, and generating
SNMP message(s) needed to emulate the service. The proxy also
emulates CMIS service responses and notifications by converting
incoming SNMP response and trap message(s) in a similar
fashion. Thus, the proxy appears as a CMIP-based agent to the
manager, and as an SNMP-based manager to the agent. The proxy
depends on the availability of corresponding MIB definitions
translated as described in [IIMCIMIBTRANS].
Table of Contents
Status of this Memo ......................................i
Abstract ..............................................ii
Table of Contents ........................................ii
Revision History .........................................iv
1 Introduction ..........................................1
1.1 Problem Statement ...................................1
1.2 Overview of IIMC ....................................2
1.3 MIB Translation Procedures ..........................2
1.4 Native Management Model .............................3
1.5 Proxy Management Model ..............................4
1.6 Scope of this Document ..............................5
1.7 Terms and Conventions ...............................8
2 ISO/Internet Proxy Configuration ......................11
2.1 ISO/Internet Proxy Containment Tree .................11
2.2 System Objects ......................................12
2.3 Translated MIB Schema Information ...................12
2.4 IIMC Party MIB Objects ..............................14
2.5 IIMC Proxy MIB Objects ..............................14
2.6 OMNIPoint 1 Capability Object .......................16
2.7 MIB Usage ...........................................17
2.8 Retained Information ................................18
3 Elements of CMIS Service Emulation ....................18
3.1 Association Service .................................18
3.2 Object Selection - Scoping and Filtering ............19
3.3 Management Operation Services .......................20
3.4 Synchronization .....................................23
3.5 M-GET Service .......................................24
3.6 M-CANCEL-GET Service ................................25
3.7 M-SET Service .......................................26
3.8 M-ACTION Service ....................................27
3.9 M-CREATE Service ....................................27
3.10 M-DELETE Service ...................................29
Chang Expires February 5, 1994 Page ii
Draft ISO/CCITT to Internet Management Proxy 8/5/93
3.11 Management Notification Services ...................30
4 Common Procedures For CMISE Service Emulation .........31
4.1 Verifying Existence Of An Object Instance ...........32
4.2 Translating Timestamps ..............................32
4.3 Derivation of SNMP Request Parameters ...............33
4.4 Derivation Of CMIS Parameters .......................34
5 Error Message Translation .............................38
5.1 Translating SNMP Error Messages .....................38
5.2 CMIS Processing Failure .............................42
6 ISO/CCITT Systems Management Functions ................42
6.1 Event Report Management Function ....................42
6.2 Log Control Function ................................43
6.3 Scope of the EFD and Log ............................43
7 ISO/CCITT-Internet Proxy MIB ..........................44
7.1 Proxy MIB GDMO Templates ............................45
7.2 Proxy MIB ASN.1 Module ..............................55
8 Conformance Requirements ..............................57
8.1 Management Communication Requirements ...............57
8.2 Management Function Requirements ....................57
8.3 Management Information Requirements .................57
8.4 Service Emulation Requirements ......................58
9 Acknowledgments .......................................59
References ..............................................61
Appendix A (Normative)
Managed Object Conformance Statements (MOCS) ........64
Appendix B (Informative)
Example Operation ...................................65
Chang Expires February 5, 1994 Page iii
Draft ISO/CCITT to Internet Management Proxy 8/5/93
Revision History
Draft 0 - October 9, 1992
Initial draft of this document.
Draft 1 - March 28, 1993
Previous draft of this document (replaced Draft 0).
Draft 2 - May 26, 1993
Previous draft of this document (replaced Draft 1).
Draft 3 - August 5, 1993
Current draft of this document (replaces Draft 2).
This draft will undergo QA review and then be
published as Issue 1.0. OID values and MOCS proformas
will be added prior to publication.
Major Changes Since Last Revision
1. Aligned templates with changes as per [IIMCIMIBTRANS].
- Added unique naming attributes for all classes.
- Removed emulation for conceptual table classes.
- Modified DELETEATT and DELETEVALUE keywords and handling
of corresponding "status" attributes.
2. Specified the semantics of the operational and usage state
attributes in "remote system" objects. Added retransmission
and polling conditional packages to cmipsnmpProxy and
cmipsnmpProxyAgent.
3. Added mandatory support for filtering on objectClass.
4. Applied several text changes identified during review of
Draft 2.
Chang Expires February 5, 1994 Page iv
Draft ISO/CCITT to Internet Management Proxy 8/5/93
1 Introduction
This section provides an overview of ISO/CCITT and Internet
Management Coexistence (IIMC) activities, insight into the
problem being addressed by IIMC, and a brief introduction to
the strategy adopted by IIMC: use of translated MIBs in either
a proxy or native implementation. The section concludes by
describing the scope of this document, and terms and
conventions used by this document.
1.1 Problem Statement
The need for enterprise network management has been addressed
by development of network management standards within various
communities, most notably the ISO/CCITT and Internet
communities.
- The ISO/CCITT community developed the Common Management
Information Protocol (CMIP) [ISO9596-1], and related SMI
documents [ISO10165-1,2,4].
- The Internet community developed the Simple Network
Management Protocol (SNMP) [RFC1157], and its successor,
SNMPv2 [RFC1448]. The Internet SMI is defined in [RFC1155]
and [RFC1442].
These standards share a nearly common management model, but
diverge due to differing management philosophies. Although
functionally similar, the Internet and ISO/CCITT protocols and
SMIs differ in terms of their complexity and specific
operations. Business requirements for end-to-end enterprise
management include the need to integrate the management of many
different devices, potentially owned or administered by many
independent organizations. This requires components to be
accessed by ISO/CCITT management, Internet management, and
proprietary management mechanisms in a manner which presents a
unified view of the network, despite protocol and SMI
differences.
For example, many telecommunications and computer vendors,
represented by organizations such as the Network Management
Forum (NMF), and the U.S. government, as specified in the
Government Network Management Profile (GNMP), have based their
enterprise management model on the ISO/CCITT management model.
These organizations are particularly interested in integrated
management of devices that use the Internet management. This
interest is primarily due to the widespread commercial
implementation and use of such devices, especially devices that
use the Internet TCP/IP protocol suite.
Chang Expires February 5, 1994 Page 1
Draft ISO/CCITT to Internet Management Proxy 8/5/93
1.2 Overview of IIMC
This document is part of a package of ISO/CCITT and Internet
Management Coexistence (IIMC) drafts. Documents included in
this package are:
[IIMCIMIBTRANS] Translation of Internet MIBs to ISO/CCITT
GDMO MIBs
[IIMCOMIBTRANS] Translation of ISO/CCITT GDMO MIBs to
Internet MIBs
[IIMCMIB-II] Translation of Internet MIB-II (RFC1213)
to ISO/CCITT GDMO MIB
[IIMCPROXY] ISO/CCITT to Internet Management Proxy
[IIMCSEC] ISO/CCITT to Internet Management Security
These documents together comprise a package aimed at
integrating ISO/CCITT-based and Internet-based management
systems. These documents represent coexistence and
interworking efforts underway within the IIMC working group,
chartered under the auspices of the Network Management Forum
Architecture Integration ISO/Internet (AIII) technical team.
The IIMC intends to address the problem that end-to-end
management requires an integrated, unified view of the managed
network, despite differences in management protocol and
information structure. Integrated management can be
facilitated by the development of "proxy" mechanisms which
translate between functionally equivalent service, protocol,
and SMI differences to create this unified view. MIB
translation procedures can be used to support proxy management,
as well as to take advantage of existing MIB definition and
avoid duplication of effort. In this way, commercial investment
in both ISO/CCITT and Internet-based management technologies
can be preserved through deployment of common methods and tools
which support integration.
This overall strategy was outlined in a joint publication
developed by the NM Forum and X/Open entitled "ISO/CCITT and
Internet Management: Coexistence and Interworking Strategy"
[NMFTR107]. The documents included in the IIMC package are the
next level of detailed specifications which implement several
of the methodologies identified in the strategy. Additional
specifications may be defined in the future.
1.3 MIB Translation Procedures
The foundation of IIMC is provided by a pair of Management
Information Base (MIB) translation procedures.
Chang Expires February 5, 1994 Page 2
Draft ISO/CCITT to Internet Management Proxy 8/5/93
- [IIMCIMIBTRANS] specifies translation procedures for
converting MIBs from Internet MIB macro format into
ISO/CCITT GDMO template format.
- [IIMCOMIBTRANS] specifies translation procedures for
converting MIBs from ISO/CCITT GDMO template format into
Internet MIB macro format.
The IIMC approach is to specify direct translation procedures
which yield a pair of functionally-equivalent MIBs, as shown in
the following figure.
+----------------+ +--------------------+ +------------
----+
| Internet MIB | | MIB Translation | | GDMO MIB
|
| | | Procedures | |
|
| Format = | | Specified By | | Format =
|
| [RFC1212] & |---->| [IIMCIMIBTRANS] or |---->| [ISO10165-
1] & |
| [RFC1442] |<----| [IIMCOMIBTRANS] |<----| [ISO10165-
4] |
+----------------+ +--------------------+ +------------
----+
MIBs translated by these procedures may be used to take
advantage of existing MIB definitions when business needs
require deployment in a different management environment.
Translated MIBs may also be used to provide uniformity when
multiple management environments are supported by a single
system (e.g., dual stack managers). Finally, IIMC MIB
translation procedures may be used to support service emulation
by a proxy.
1.4 Native Management Model
The basic model for ISO/CCITT and Internet management is
illustrated in the following diagram.
Chang Expires February 5, 1994 Page 3
Draft ISO/CCITT to Internet Management Proxy 8/5/93
Manager Agent
+-----------------------+ +----------------------+
|+---------------------+| |+-------------------+ |
|| Management || || Managed | |
|| Applications || || Resources | |
|+---------------------+| |+-------------------+ |
| | | | | |
| | | | | |
|+-----------+---------+| |+----------+---------+|
|| Manager | MIB || || Agent | MIB ||
|+-----------+---------+| |+----------+---------+|
| | | | | |
| | Management | | | Management |
| | Services | | | Services |
+-----------------------+ +----------------------+
| Management Protocol | | Management Protocol |
+-----------------------+ +----------------------+
^ ^
| |
+------------------------------------+
Protocol Messages
Within IIMC documents, this model is referred to as the
"native" management model. MIBs translated using IIMC
procedures can be used by "native" agent implementations. For
example, an ISO/CCITT agent can make visible TCP/IP managed
resources using the translated GDMO version of the Internet
MIB-II [RFC1213] specified by [IIMCMIB-II]. Dual-stack managers
or agents may also be implemented which support both the
original MIB and the translated MIB generated using IIMC-
specified procedures.
1.5 Proxy Management Model
Chang Expires February 5, 1994 Page 4
Draft ISO/CCITT to Internet Management Proxy 8/5/93
The basic model for ISO/CCITT to Internet proxy management is
illustrated in the following diagram. This proxy is specified
by [IIMCPROXY]. A similar approach could also be taken to
specify an Internet to ISO/CCITT proxy, although no such IIMC
document is currently specified.
Manager Proxy
Agent
+-----------------------+ +---------------------+ +---------
-------------+
|+---------------------+| |+------+ +----------+| |+--------
-----------+ |
|| Management || || GDMO | | Internet || ||
Managed | |
|| Applications || || MIB | | MIB || ||
Resources | |
|+---------------------+| |+------+ +----------+| |+--------
-----------+ |
| | | |+-------------------+| | |
|
| | | || Service || | |
|
| | | || Emulation || | |
|
| | | ||(scoping) || | |
|
| | | || (filtering) || | |
|
|+-----------+---------+| || (operations) || |+--------
--+---------+|
|| ISO/CCITT | GDMO || || (message || ||
Internet | Internet||
|| Manager | MIB || || transformation)|| || Agent
| MIB ||
|+-----------+---------+| |+-------------------+| |+--------
--+---------+|
| | | | |CMIS | | | |
|
| | CMIS Services | | |Services | | | |
SNMP "Services" |
| | | | | | | | |
|
| | | | | SNMP| | | |
|
| | | | | "Services"| | | |
|
+-----------------------+ +---------------------+ +---------
-------------+
| CMIP | | CMIP | SNMP | |
SNMP |
+-----------------------+ +---------------------+ +---------
-------------+
^ ^ ^
^
Chang Expires February 5, 1994 Page 5
Draft ISO/CCITT to Internet Management Proxy 8/5/93
| | |
|
+---------------------+ +------------------
-+
CMIP Messages SNMP Messages
This ISO/CCITT to Internet proxy provides emulation of CMIS
services by mapping to the corresponding SNMP message(s)
necessary to carry out the service request. The service
emulation allows management of Internet objects by an ISO/CCITT
manager. The left hand side of the proxy behaves like an
ISO/CCITT agent, communicating with the ISO/CCITT manager using
CMIP protocols. The right hand side of the proxy behaves like
an Internet manager, communicating with the Internet agent
using SNMP protocols.
The proxy relies on the existence of a pair of directly-related
MIB definitions, where the Internet MIB has been translated
into ISO/CCITT GDMO using the procedures specified in
[IIMCIMIBTRANS]. The proxy uses these MIB definitions and rules
to provide run-time translation of management information
carried in service requests and responses.
The proxy is designed with a specified interface between the
proxy and the underlying protocol stacks, and so deals
primarily in terms of CMIS services and SNMP "services". The
proxy emulates services such as CMIS scoping and filtering,
processing of CMIS operations, and forwarding/logging of CMIS
notifications by performing a mapping process which must be
tailored for each protocol (for example, SNMPv1 and SNMPv2 are
variants of the same protocol mapping process).
1.6 Scope of this Document
The intent of this document (IIMCPROXY) is to facilitate the
use of ISO/CCITT CMIP-based managers to perform integrated
management of networks via proxy management of networks that
are accessed using Internet SNMP-based agents. There are two
major differences between CMISE and SNMP services: the
structure of management information, and the management
operations supported by the underlying protocols. The
ISO/Internet Proxy architecture as shown in section 1.2
provides CMISE service emulation. In another words, the
ISO/Internet Proxy acts as a CMIP-based agent with respect to
the manager to allow management of Internet objects by the
ISO/CCITT manager. CMIS requests are processed by the
ISO/Internet proxy and CMIS responses are returned by the
ISO/Internet proxy. SNMP traps and Inform requests are
converted to CMIS notifications by the ISO/Internet proxy. The
implementation of the proxy requires that the Internet MIBs be
mapped to ISO/CCITT GDMO definitions.
1.6.1 Approaches to Service Emulation
Chang Expires February 5, 1994 Page 6
Draft ISO/CCITT to Internet Management Proxy 8/5/93
As described by [NMFTR107], there are different approaches for
mapping Internet MIBs and ISO/CCITT MIBs.
- The "direct translation" approach maps each Internet
object to a newly defined ISO/CCITT GDMO object that
contains: 1) the same information as contained in the
Internet object; and 2) the attributes that are inherited
from the ISO/CCITT Top object class.
- The "abstract translation" approach maps Internet objects
to different ISO/CCITT GDMO objects. For example, the MIB-
II system object is similar to, and could be represented
by, the ISO/CCITT system object. The abstract translation
approach can also be used to map several Internet objects
to a single ISO/CCITT GDMO object which provides only a
summary view of the original Internet objects.
Either or both approaches could be used by an ISO/CCITT manager
to manage Internet agents. This document uses the "direct
translation" approach.
To perform the CMISE service emulation, the ISO/Internet proxy
can use either of the approaches described by [NMFTR107] to
retrieve or modify Internet MIB information.
- In the "stateless" approach, the proxy does not maintain
the Internet agent's MIB data. Instead, for each received
CMIS request, the ISO/Internet proxy generates one or more
SNMP requests to the Internet agent in order to achieve
the same intent of the CMIS request.
- The "stateful" approach requires the proxy to replicate an
Internet agent's MIB locally, and to send periodic
(unsolicited) requests to Internet agents to keep the
replicated MIB current. The ISO/Internet proxy then tries
to fulfill each incoming CMIS request by using locally-
replicated MIB data, instead of sending SNMP requests to
the Internet agent.
Stateful and stateless are two extremes; any approach falls
somewhere in between.
The "stateful" approach usually provides better response time,
but has the drawback that the data retrieved might not be
current. In this approach, the poll frequency used to update
the locally-replicated MIB has a significant effect on the
accuracy of the response.
This document uses the "stateless" approach in which the proxy
responds to incoming CMIS requests by generating appropriate
SNMP requests. Furthermore, SNMP traps and inform requests are
converted to CMIS notifications.
Chang Expires February 5, 1994 Page 7
Draft ISO/CCITT to Internet Management Proxy 8/5/93
If necessary, the static Internet MIB data retrieved by the
ISO/Internet proxy could be cached by the proxy in order to
improve the response time of an operation. This document makes
no assumption that the proxy caches static information, and so
takes no advantage of information which might be cached.
1.6.2 Proxy Inputs and Outputs
This document describes a proxy which emulates CMIS services
through generation of appropriate SNMP protocols. The proxy is
based on certain inputs and outputs, as shown below in Tables 1
and 2.
CMIS services [ISO9595] are supported by CMIP version 2
protocol [ISO9596-1]. SNMP protocols are as defined for SNMPv1
[RFC1157] and SNMPv2 [RFC1448]. The emulation is slightly
different, depending upon whether SNMPv1 or SNMPv2 protocols
are being used.
+------------------------------+----------------------+
| Service | Source |
+------------------------------+----------------------+
| ACSE Associate Indication | CMIP Stack |
| ACSE Release Indication | CMIP Stack |
| ACSE Abort Indication | CMIP Stack |
| CMIS Get Indication | CMIP Stack |
| CMIS Cancel Get Indication | CMIP Stack |
| CMIS Set Indication | CMIP Stack |
| CMIS Create Indication | CMIP Stack |
| CMIS Delete Indication | CMIP Stack |
| CMIS Action Indication | CMIP Stack |
| CMIS Event Report Confirm | CMIP Stack |
| SNMPv1 Get Response | SNMPv1 Stack |
| SNMPv1 Trap | SNMPv1 Stack |
| SNMPv1 Error | SNMPv1 Stack |
| SNMPv2 Trap | SNMPv2 Stack |
| SNMPv2 Get Response | SNMPv2 Stack |
| SNMPv2 Get Bulk Response | SNMPv2 Stack |
| SNMPv2 Inform Request | SNMPv2 Stack |
| SNMPv2 Error | SNMPv2 Stack |
+------------------------------+----------------------+
Table 1 - Proxy Inputs
Chang Expires February 5, 1994 Page 8
Draft ISO/CCITT to Internet Management Proxy 8/5/93
+------------------------------+----------------------+
|Service | Target |
+------------------------------+----------------------+
| ACSE Associate Response | CMIP Stack |
| ACSE Release Response | CMIP Stack |
| ACSE Abort Request | CMIP Stack |
| CMIS Get Response | CMIP Stack |
| CMIS Cancel Get Response | CMIP Stack |
| CMIS Set Response | CMIP Stack |
| CMIS Create Response | CMIP Stack |
| CMIS Delete Response | CMIP Stack |
| CMIS Action Response | CMIP Stack |
| CMIS Event Report Indication | CMIP Stack |
| SNMPv1 Get Request | SNMPv1 Stack |
| SNMPv1 Set Request | SNMPv1 Stack |
| SNMPv1 Get Next Request | SNMPv1 Stack |
| SNMPv2 Get Request | SNMPv2 Stack |
| SNMPv2 Set Request | SNMPv2 Stack |
| SNMPv2 Get Next Request | SNMPv2 Stack |
| SNMPv2 Get Bulk Request | SNMPv2 Stack |
+------------------------------+----------------------+
Table 2 - Proxy Outputs
This document assumes that CMIP PDUs and SNMP PDUs received by
the ISO/Internet proxy are always properly encoded (i.e., the
underlying protocol stacks ensure the correctness of the
service indications and confirmations that are passed up to the
ISO/Internet proxy).
The security architecture, services, protocols, and mechanisms
for the ISO/Internet proxy shall be as defined in [IIMCSEC].
1.7 Terms and Conventions
This document assumes that the reader is familiar with
ISO/CCITT management and Internet management, and the
terminology of each. The term "SNMP" is used throughout this
document to indicate either SNMPv1 or SNMPv2, unless a
distinction needs to be made.
Other terms and conventions used throughout this document
include the following.
1. ISO/CCITT manager: An application entity that implements
[ISO9596-1] and acts in the manager role.
2. Internet agent: An application entity that supports the
agent role of one or more of the SNMP protocols, such as
[RFC1157] or [RFC1448].
Chang Expires February 5, 1994 Page 9
Draft ISO/CCITT to Internet Management Proxy 8/5/93
3. ISO/Internet Proxy: An application entity that is
responsible for emulating CMIS requests by a) generating
SNMP requests, b) using SNMP responses to generate CMIS
responses, and c) mapping SNMP Traps and InformRequests to
CMIS notifications, all between a given (ISO/CCITT
manager, Internet agent) pair. A proxy may concurrently
support more than one (ISO/CCITT manager and Internet
agent) pair.
4. Known Internet agents: A set of one or more Internet
agents that an ISO/Internet proxy has knowledge of. Each
known Internet agent is represented by an instance of the
proxy object. This document defines the cmipsnmpProxyAgent
object class.
5. Known SNMP Party Object: A set of one or more SNMP parties
that an ISO/Internet proxy has knowledge of. Each known
SNMP party is represented by an instance of the partyEntry
object as defined in [IIMCSEC].
6. Local object (instance): An object instance that is
implemented by the proxy itself (for example, the
cmipsnmpProxy and cmipsnmpProxyAgent classes defined in
section 7).
7. Remote object (instance): An object instance that
physically resides within an Internet agent is considered
a "remote object" (for example, Internet MIB-II objects
like system, tcp, and udp).
8. Multiple Instance Object: An object class that may have
more than one object instance. For example, Internet MIB
table entries.
9. Delete Information: The object identifier of the attribute
and its attribute value used to indicate that a particular
row of a table is deleted. In the case of SNMP V2,
rowStatus may be used to represent the delete information.
10. Proxy System Object: The [ISO10165-2] DMI system managed
object instance that represents the proxy itself.
11. Remote System Object: The [ISO10165-2] DMI system managed
object instance that represents the remote proxied device
on which the Internet agent resides.
Chang Expires February 5, 1994 Page 10
Draft ISO/CCITT to Internet Management Proxy 8/5/93
Abbreviations
CMIP: Common Management Information Protocol
CMIS: Common Management Information Service
CMISE: Common Management Information Service Element
DN: Distinguished Name
MIB: Management Information Base
MOC: Managed Object Class (CMIP)
MOI: Managed Object Instance (CMIP)
MIT: Management Information Tree (naming tree)
OID: ASN.1 Object Identifier
PDU: Protocol Data Unit
RDN: Relative Distinguished Name
SNMP: Simple Network Management Information Protocol
SNMPv1: Simple Network Management Information Protocol
version 1 [RFC1157]
SNMPv2: Simple Network Management Information Protocol
version 2 [RFC1448]
Chang Expires February 5, 1994 Page 11
Draft ISO/CCITT to Internet Management Proxy 8/5/93
2 ISO/Internet Proxy Configuration
In order for the ISO/Internet proxy to interwork with the known
Internet agents, the proxy needs to know initialization
information such as the transport address, network address,
protocol version, and security policy for each of the known
Internet agents. Such configuration may be done through an off-
line process, or through an on-line management exchange not
specified by this document.
2.1 ISO/Internet Proxy Containment Tree
The proxy shall support a forest of object instance trees,
each rooted at the ISO/CCITT system managed object defined by
[ISO10165-2], with one system object instance for each
supported Internet agent, and one system object instance for
the proxy itself. Each ISO/CCITT system object is
distinguished by the value of its systemId or systemTitle
attribute, containing the name associated with the Internet
agent or proxy application. This ISO/CCITT to Internet Proxy
containment tree is shown below.
"Containment Object"
|
+----------------+-+--------------------------+
| | ... |
Proxy System Remote System 1 Remote System N
| | |
+---+-+-----+ +---+-+---+ +--+--+----+
| | ... | | | ... | | | .... |
Objects in Objects in Objects in
Proxy System Remote System 1 Remote System N
The "Proxy System" is the [10165-2] "system" managed object
instance that represents the proxy itself. The Proxy System
contains all objects representing resources within the proxy
itself, including the cmipsnmpProxy and cmipsnmpProxyAgent
managed objects.
The "Remote System" is the [10165-2] "system" managed object
instance that represents the remote proxied device on which the
Internet agent resides. The Remote System contains all objects
that are implemented by the remote Internet agent. These would
include [IIMCMIB-II] "internetSystem", and any other object
supported by the Internet agent.
All objects in the above containment tree can be accessed by
scoping from the "Containment Object". This may be an instance
of any managed object class. One possible "Containment Object"
is the so-called global root (i.e., "CCITT Rec. X.660 | ISO/IEC
9834-1 : 1992":root). In this case, scoped requests including
Chang Expires February 5, 1994 Page 12
Draft ISO/CCITT to Internet Management Proxy 8/5/93
all Remote Systems can be achieved by using a management
operation with the base object class equal to "actualClass" and
the base object instance name equal to "{}". The proxy may
support other alternative "Containment Objects"; this choice is
left to the implementor.
2.2 System Objects
The "Proxy System" object particular to the proxy shall be
created automatically by the proxy during its local
initialization.
The "Remote System" object particular to an Internet agent
system shall be automatically created/deleted by the proxy when
an associated cmipsnmpProxyAgent object instance in the Proxy
MIB is created/deleted. The Distinguished Name of this system
object shall have the same value as the cmipsnmpProxyId
attribute in the associated cmipsnmpProxyAgent object instance.
Creation/deletion of the system object via management operation
is not allowed.
The operationalState and usageState attributes of the "Remote
System" object indicate the perceived state of the Internet
agent. These two attributes are the same as those defined in
[ISO10165-2]. The proxy emulates CMIS M-GET requests on these
attributes by issuing SNMP Get or Get-Next requests on an
attribute of the corresponding internetSystem object. If no SNMP
response is received, a CMIS processingFailure error is
returned. Otherwise, if an SNMP response is received, the
Internet agent is considered reachable and state attributes
value(s) are returned as follows.
- For operationalState attribute, if the Internet agent is
reachable, the value "enabled" is returned. This implies
that the value "disabled" is never returned.
- For the usageState attribute, if the Internet agent is
reachable, the value "active" is returned. This implies
that the other values, "idle" and "busy", are never
returned. (The proxy has no way of determining actual
usage of the Internet system.)
The proxy shall not instantiate any other conditional packages
when creating remote system objects.
2.3 Translated MIB Schema Information
To perform CMISE service emulation, the ISO/Internet proxy
requires the Internet MIB's schema information, described in
ISO/CCITT GDMO templates. These templates shall be derived
from the original Internet MIB according to the procedures
defined by [IIMCIMIBTRANS].
The proxy run-time translation of parameters and protocol
translation procedures defined in this document depend on the
Chang Expires February 5, 1994 Page 13
Draft ISO/CCITT to Internet Management Proxy 8/5/93
MIB translation, naming and registration procedures defined in
[IIMCIMIBTRANS]. The translation and registration procedures
defined in that document are structured such that the maximum
amount of information is preserved to facilitate the
translation process.
An example containment tree for an agent supporting the
ISO/CCITT GDMO Internet MIB-II [IIMCMIB-II] (derived from the
Internet MIB-II [RFC1213]) is illustrated below. A proxy would
have multiple instances of such a tree for each Internet agent
supported. (The actual structure of the each containment tree
depends upon the MIB(s) supported by the proxy.)
"Rec. X.721 | ISO/IEC 10165-2 : 1992" : system
|
|-- internetSystem
|
|-- at --- atEntry
|
|-- egp --- egpNeighEntry
|
|-- icmp
|
|-- interfaces --- ifEntry
|
|-- ip --- ipRouteEntry
| |
| |---- ipAddrEntry
| |
| |---- ipNetToMediaEntry
| |
| |---- ipForwardEntry
|
|-- snmp
|
|-- tcp --- tcpConnEntry
|
|-- udp --- udpEntry
As specified in [IIMCIMIBTRANS], NAME BINDINGs for ISO/CCITT
GDMO object classes derived from Internet MIB group and table
entry types can be automatically inferred from the Internet
registration hierarchy. Thus, object classes derived from
Internet table entries are bound to the group object classes
with which the table entries are associated. Also, object
classes derived from Internet groups are bound to the ISO/CCITT
system object class.
Chang Expires February 5, 1994 Page 14
Draft ISO/CCITT to Internet Management Proxy 8/5/93
2.4 IIMC Party MIB Objects
Information regarding security policy when accessing agents is
contained in Party MIB objects. Binding the Party MIB objects
as subordinates of the system object which represents an
individual Internet agent allows security policy to be applied
on a per Internet agent basis. The Party MIB information can be
used by the proxy in a manager role when security services
enforcing security policy are implemented in the Internet
agent. The services enforced may be authentication, access
control, confidentiality and integrity as defined in [RFC1446].
In those situations where the agents may not implement the
access control security service on requests from the ISO/CCITT
manager (e.g., SNMPv1 agents), the proxy may enforce those
services on behalf of the Internet agent. The policy regarding
where access control is to be applied is controlled by
variables in the cmipsnmpProxy and cmipsnmpProxyAgent managed
objects defined in section 7.
The policy regarding security services other than access
control, must always be enforced by the Internet agent.
A containment tree diagram for IIMC Party MIB managed object
classes which may be instantiated at the proxy is illustrated
below. The IIMC Party MIB is subordinate to the ISO/CCITT
system managed object that represents the Internet agent.
"Rec. X.721 | ISO/IEC 10165-2 : 1992" : system
|
|-- partyMIBObjects
|
+-- partyEntry
|
+-- contextEntry
2.5 IIMC Proxy MIB Objects
The IIMC Proxy MIB defines a set of objects for specifying the
information that is needed for both community-based and party-
based SNMP management on a per Internet agent basis.
The Proxy MIB consists of a cmipsnmpProxy managed object which
contains cmipsnmpProxyAgent object instances, one for each
agent being managed by the proxy. The cmipsnmpProxy object
class is an immediate subordinate of the "Proxy System" object
class. The cmipsnmpProxy object also contains an
snmpSecurityParameter object instance which contains default
security information.
Chang Expires February 5, 1994 Page 15
Draft ISO/CCITT to Internet Management Proxy 8/5/93
Each cmipsnmpProxyAgent object has information which identifies
an Internet agent and how the agent may be reached. Its naming
attribute, which contains the administratively assigned name of
the managed device where the Internet agent is located, is used
in the naming tree to identify the SNMP managed device.
Creation of a cmipsnmpProxyAgent object instance to represent
an Internet agent shall result in the instantiation of a
corresponding "Remote System" object representing the Internet
agent. The naming attribute value of the "Remote System" shall
be the same as the name of the corresponding cmipsnmpProxyAgent
object instance. It is recommended that a "OP1 Library Vol.
4":capabilityObject also be created for the proxy.
If the proxy uses an unreliable transport to communicate with
the Internet agent, some mechanism may be required to monitor
the reachability of the Internet agent and the reliability of
the message delivery between the proxy and the Internet agent.
Two conditional packages are defined for this purpose.
Retransmission Package
If this package is requested during object creation and
the proxy supports the requested retransmission
requirements, this package influences SNMP request
retransmission by the proxy. SnmpMsgTimeout indicates how
long the proxy should wait to receive each SNMP response
before "timing out". If the snmpMsgRetryLimit is set to
zero, the proxy will only send each SNMP request once. If
the snmpMsgRetryLimit is set to one, each SNMP request may
be sent twice at most - once for the original request and
once for the retry following a timeout. When a timeout
occurs and the retry limit has been reached, a CMIS
processingFailure error in generated. The timeout and
retry limit applies to each individual SNMP request, and
not to the CMIS request being emulated.
Polling Package
If this package is requested during object creation and
the proxy supports the requested retransmission
requirements, this package specifies the interval for
polling the Internet agent's reachability. When polling
is enabled (has a non-zero value), the proxy issues
periodic SNMP Get or Get-Next requests on the Internet
system to verify reachability of the Internet agent. If
the Internet agent does not respond, a CMIS
communicationsAlarm shall be generated indicating loss of
signal.
These two packages can optionally be instantiated within
the cmipsnmpProxy and/or cmipsnmpProxyAgent objects. If
these packages are instantiated in the cmipsnmpProxy
object, then these attribute values apply by default to
all Internet agents. If these packages are instantiated in
an individual cmipsnmpProxyAgent object, then the values
Chang Expires February 5, 1994 Page 16
Draft ISO/CCITT to Internet Management Proxy 8/5/93
specified there apply to the associated Internet agent,
over-riding any default values specified by the superior
cmipsnmpProxy object.
The cmipsnmpProxyAgent object may be created by management
operation or automatically. For example, the proxy may
support discovery of Internet agents, whereby the
discovered Internet agents, the associated system object,
and capability object shall be created automatically by
the proxy itself.
The administrativeState of the cmipsnmpProxyAgent can be
locked/unlocked via management operation. If the
administrativeState is locked, all incoming CMIS requests
for this agent are not carried out. ProcessingFailure
with specificErrorInfo set to adminStateLocked (defined in
section 7.1.4) shall be returned for all subsequent CMIS
requests, and no notifications are generated with this
cmipsnmpProxyAgent's internetSystem as the source managed
object.
This document refers to instances of IIMC Proxy MIB object
classes as "local objects" or as "local object instances".
A containment tree diagram for ISO/CCITT proxy MIB managed
object classes is illustrated below.
"Rec. X.721 | ISO/IEC 10165-2 : 1992" : system
|
+-- cmipsnmpProxy
|
+--cmipsnmpProxyAgent
|
+--snmpSecurityParameter
IIMC Proxy MIB GDMO definitions are described in section 7.
2.6 OMNIPoint 1 Capability Object
If used, the "OP1 Library Vol.4":capability object particular
to an Internet agent system shall be automatically created and
deleted by the proxy when the associated cmipsnmpProxyAgent
object in the Proxy MIB is created and deleted.
The following text describes one possible implementation of
gathering information defined in the Capability object's
supportedObjectClassList. When the cmipsnmpProxyAgent is
created, or when the supportedObjectClassList attribute
changes, the proxy shall find out all the object classes
defined in all the GDMO documents described in the
supportedMIBs attribute. The proxy then forms an SNMP Get Next
Request with all the object classes (translated to the OID used
by the Internet agent) in a variable binding list to find out
whether a particular object class is supported by the Internet
Chang Expires February 5, 1994 Page 17
Draft ISO/CCITT to Internet Management Proxy 8/5/93
agent. The proxy then fills the supportedNameBindingList by
finding out all the NAME BINDINGs used by the object classes in
the supportedObjectClassList.
2.7 MIB Usage
The information described in sections 2.1 through 2.6 is
maintained by the proxy and used to perform run-time
translation between corresponding CMIS and SNMP parameters.
The following definitions are extracted from [IIMCIMIBTRANS]
clause 2.3.1, where (c) and (a) refer to class and attribute,
respectively.
From [IIMCIMIBTRANS] clause 2.1:
{classOID} ::= {iimcAutoTrans
<internetEntityId>(c)}
and
{attributeOID} ::= {iimcAutoTrans
<internetEntityId>(a)}
From [IIMCIMIBTRANS] clause 2.2, the ISO/CCITT naming attribute
value contains either an ASN.1 NULL value, or a list of index
variables in an ASN.1 SEQUENCE with their values represented in
their appropriate syntax. (the "( )" indicates "contents of"):"
(naming attribute) ::= <internet instanceId>
where the <internet instanceId> is an ASN.1 NULL, or a SEQUENCE
identifying the INDEX attributes used to name the object class,
and their syntax. Managed objects for which only a single
instance resides in the managed system, e.g., tcp, ip, shall
use the ASN.1 NULL for their value. Managed object classes
that may have multiple instances, e.g., table entries, shall
use as their value an ASN.1 SEQUENCE that contains values of
the attributes derived from internet objects identified in the
INDEX (or AUGMENTS) clause of the Internet Macro from which the
object class is derived, as defined in [RFC1155] or [RFC1442].
For example, the ISO/CCITT naming attribute value for the
instance of ipRouteEntry specific to IP address "129.83.2.17"
contains the ipDestination index variable as an IP address
represented in an ASN.1 OCTET STRING of size 4 as specified in
[RFC1242].
The Internet uses the following convention to uniquely identify
an Internet object instance:
{internet object name}::= {<internetEntityId>(a)
<internet instanceId>}
Chang Expires February 5, 1994 Page 18
Draft ISO/CCITT to Internet Management Proxy 8/5/93
Refer to [IIMCIMIBTRANS] for additional detail.
2.8 Retained Information
The proxy must retain information obtained from the ISO/CCITT
manager during association establishment, and for individual
CMIS requests on the association.
For each outstanding CMIS request, the proxy needs to maintain
the ISO/CCITT invoke id, object class and object instance.
When SNMP responses are received, the proxy shall use the
retained information to form the associated parameters in CMIS
responses.
For scoped CMIS requests, the proxy shall maintain some state
information to keep track of the portion of the Internet MIB
that is being traversed.
3 Elements of CMIS Service Emulation
The following sections describe the conceptual process for
performing CMIS service emulation. In an actual
implementation, it should be possible to combine some of the
processing. It is highly recommended that the implementors of
the ISO/Internet proxy combine the processes where possible to
optimize the implementation.
3.1 Association Service
The proxy should provide the association service as defined in
section 8.1 of [ISO9596-1]. This service includes association
establishment and association release.
In ISO/CCITT systems management, management entities may
exchange initialization information during the association
establishment phase. Such information is used only by the proxy
for its own configuration and is not conveyed to the
communicating Internet agents.
This document does not define any application context; however,
a proxy may be required to support the following application
contexts as defined in the ISO standards and CCITT
recommendations:
ISO Systems Management application context; or
CCITT TMN application context one.
CMIP and SMASE functional units may be negotiated between the
ISO/CCITT manager and the ISO/Internet proxy. Once a set of
functional units is agreed, the proxy will ensure only the
agreed services are accepted over the association.
Chang Expires February 5, 1994 Page 19
Draft ISO/CCITT to Internet Management Proxy 8/5/93
The CMIP protocol used between the ISO/CCITT manager and the
ISO/Internet proxy is a connection-oriented protocol which
requires an association be maintained throughout the management
exchange(s). The protocol between the proxy and the Internet
agent, however, may be a connection-less protocol which does
not require the existence of an association.
3.2 Object Selection - Scoping and Filtering
Managed object selection is used to identify a set of managed
object instances in the management information tree (MIT) to
which a CMIS request applies. Managed object selection is
performed in two phases: scoping; and then, filtering. Scoping
is used to select candidate object instances in the MIT to
which operations may apply. A filter is then applied to
attributes of the previously scoped object instances in order
to identify the subset of object instances on which the CMIS
operation is to be performed.
If no filter is specified, the CMIS request will be performed
for all object instances identified by the scope parameter. If
no scope parameter is specified, the default is the base
managed object instance only.
There are different ways of performing the scoping operation,
depending on the implementation. This document specifies one
possible way of providing the managed object selection service.
The proxy has no direct knowledge of current object instances
that exist in the Internet agent. Therefore, it must first
determine the existence of an object instance before it knows
whether it is within the scope. Obviously, all objects in the
scope must be instances of object classes that are within the
scope. Thus, the proxy should first determine the set of
object classes within the scope, and then discover what
instances of those object classes actually exist in the
Internet agent. This set of object classes that are within the
scope are called the "object class group" (OCG).
The following pseudo code algorithm specifies a generic method
of determining the members of an "object class group".
Define the set of object classes at the current level in the
naming tree that are being processed as the "class level group"
(CLG).
Define the set of object classes at the next level in the
naming tree that are to be processed after the CLG as the "next
level group" (NLG).
Define the managed object class named by the incoming request
as the "base managed object" (BMO).
Chang Expires February 5, 1994 Page 20
Draft ISO/CCITT to Internet Management Proxy 8/5/93
Minimum Level and Maximum Level are derived from the CMIS scope
parameter, as follows.
CMIS Scope Min Level Max level
---------- --------- -------
baseObjectAlone 0 0
firstLevelOnly 1 1
individualLevels N N
baseToNthLevel 0 N
wholeSubtree 0 Depth of the tree
CLG = {BMO};
OCG = {}; /* empty set */
currentScope = 0;
WHILE ( currentScope <= Maximum Level )
NLG = {children of objects in CLG};
IF (currentScope >= Minimum Level)
THEN OCG = {union of OCG and CLG};
CLG = NLG;
currentScope = currentScope + 1;
ENDWHILE;
The determination of the set NLG as {children of objects in
CLG} may be done using implementation-dependent internal data
structures of the proxy.
An alternative method to determine NLG is to use the NAME
BINDING templates directly. The following algorithm could then
be used to determine the NLG.
WHILE (CLG not equal to {})
Remove an object from CLG;
FOR (all name bindings in this proxy's associated
Capability object)
IF object == SUPERIOR
THEN NLG = {union of the
SUBORDINATE object and NLG};
ENDFOR;
ENDWHILE;
3.3 Management Operation Services
If the specified instances (i.e., those selected by scoping
process) are "local objects", the proxy performs the services
using local means.
If the specified instances are "remote objects", then the
following steps apply. Any objects that physically reside in
the Internet agents are considered "remote objects". For
example, Internet MIB II objects like system, tcp, and udp are
considered "remote objects".
Chang Expires February 5, 1994 Page 21
Draft ISO/CCITT to Internet Management Proxy 8/5/93
1) Determine if the attributes specified by the filter
expression (if any) belong to the object class. If not,
remove the object class from the object class group.
2) Determine if an instance of the object exists by
attempting to retrieve, for the first instance, all of the
attributes specified in the CMIS filter and the
attributeId list or attribute list.
i) For single instance objects (i.e., Internet group
objects), if the object contains at least one
attribute that is implemented by the remote Internet
agent, use an SNMP Get Request or Get-Next Request
with the parameters translated according to section
4.
If the object does not contain any attribute that is
implemented in the remote Internet agent (e.g., the
Internet MIB-II at group), then the object exists if
and only if there exists a subordinate object (table
entries). The proxy shall attempt to determine if
there exists a subordinate object by issuing an SNMP
Get-Next Request using as an argument the Internet
object name for the object, <internetEntityId>(c).
If the SNMP response contains an Internet object
that translates to an attribute of a subordinate of
the object, then the object exists. If the object
does not exist, remove it from the
object class group.
ii) For multiple instance objects (i.e., Internet table
entry objects), use an SNMP Get-Next Request with the
parameters translated as shown in section 4. This
will result in the retrieval of the first instance of
the translated Internet objects (i.e., a table
entry). If the resulting table entry has been
deleted, or is otherwise unavailable for retrieval,
then go to step 5.
3) If the filter exists and it evaluates to FALSE, then
perform no further processing on the object. However,
for multiple instance objects, save the results of step 2
part (ii).
4) If no filter is specified or the filter evaluates to TRUE,
attempt to perform the operation on the object, as
follows.
- If the CMIS operation is M-GET, the M-GET is
completed from the Internet agent. Formulate the
appropriate CMIS M-GET response and send it to
the manager.
Chang Expires February 5, 1994 Page 22
Draft ISO/CCITT to Internet Management Proxy 8/5/93
- If the CMIS operation is M-SET, perform the
corresponding SNMP Set Request on the Internet
objects. When the SNMP Response returns,
formulate the appropriate CMIS M-SET response
and send it to the manager.
If the proxy gets the variable(s) to be modified
during emulation of CMIS M-SET and any variable
already has the requested value, the proxy shall
still generate the SNMP Set request to guarantee
that all behavior associated with the operation
is executed.
- If the CMIS operation is M-CREATE, perform the
create on the Internet objects (conceptual row
elements) using the algorithm appropriate to the
object. The proxy shall verify that none of
the attribute values violate the object
definition before it performs the SNMP
operation. When the create process finishes,
formulate the appropriate CMIS M-CREATE response
and send it to the manager.
- If the CMIS operation is M-DELETE, perform the
delete on the Internet objects. When the SNMP
Response returns, formulate the appropriate CMIS
M-DELETE response and send it to the manager.
5) For multiple instance objects, use an SNMP Get-Next
Request, with the parameters translated according to
section 4, and with the <internet instanceId> set to the
values retrieved for the previous instances for all
Internet object names. This will result in the retrieval
of the next instance of the translated Internet objects.
If the Internet object instances are not of the same type
as those requested, then all instances of the multiple
instance object class have been processed; go to step 6.
If the Internet object instances are of the same type as
those requested then retain the results of the Get-Next
Request for the next iteration and repeat steps 3-5.
In order to reduce the amount of traffic generated by
multiple Get-Next requests, the proxy can use the SNMPv2
Get-Bulk request with the non-repeaters parameter set to
zero and the max-repetitions set to some arbitrary value
(either by guessing or based on previous knowledge).
Setting non-repeaters to zero makes the Get-Bulk operation
behave like Get-Next.
6) Attempt to select another object class from the object
class group. If one exists, go to step 1; otherwise,
return an appropriate final CMIP PDU (e.g., empty M-GET or
M-SET response) and terminate processing the request.
Chang Expires February 5, 1994 Page 23
Draft ISO/CCITT to Internet Management Proxy 8/5/93
3.4 Synchronization
If the ISO/Internet proxy receives a CMIS "atomic" request, but
cannot perform the operation atomically, the "synchronization
not supported" CMIS error response should be returned to the
ISO/CCITT manager.
If SNMPv1 is used, the types of atomic requests that the
ISO/Internet proxy can perform are as follows.
1) If all the instances selected by a scoped CMIS request are
"local object instances", then the ISO/Internet proxy can
perform the CMIS request locally (and atomically); and
2) If the CMIS request can be performed by the ISO/Internet
proxy using a single SNMP request, then the operation can
also be performed atomically.
In SNMPv1, either a Get or Set operation would fail if
the operation on any selected variable(s) failed. This
remains true for SNMPv2 Set operations, but not for
SNMPv2 Get operations. Using SNMPv2, if you request 4
variables in a Get request, and there is an error in one
of the variables, you get a response with 3 valid values
and one error. The proxy shall fail a CMIS "atomic"
request if the corresponding SNMPv2 Get operation is only
partially successful.
For a "best effort" request, the ISO/Internet proxy should try
to perform the request on all the instances specified by the
request. Since the SNMP protocol supports only "atomic"
operations, an operation (especially an SNMP Set Request
operation) on multiple variables may be rejected if the
operation on any one of the selected variables failed. Upon
receiving such an error, the proxy should retry the request by
sending multiple requests with each request containing only a
single variable. In the time window in which these SNMP
requests are being processed, another SNMP Set Request could be
issued which could modify the value of a selected variable.
For this reason, the complete integrity of a CMIS scoped
request cannot be guaranteed. A proxy which complies with this
document is not required to detect or avoid this situation, and
will not usually report any error if this situation occurs.
Chang Expires February 5, 1994 Page 24
Draft ISO/CCITT to Internet Management Proxy 8/5/93
3.5 M-GET Service
The following sub-sections describe how the M-GET service may
be emulated. Upon receiving a CMIS M-GET request, the proxy
first verifies the existence of the base managed object. The
procedures for verifying the existence of a managed object is
described in section 4.1.
3.5.1 Form The Request
If the CMIS request's attributeIdList parameter is empty
(selects all attributes), the proxy shall query the schema
information to find out what attributes are specified for the
requested object class.
If the CMIS request's attribute specifies a non-null
attributeIdList, the proxy shall verify that the identified
attribute(s) are specified for the object class. If the
identified attribute is not specified in the object class, the
proxy shall return a noSuchAttribute CMIS error without sending
SNMP requests to the Internet agent.
For all attributes that are specified in the object, an SNMP
Get or SNMP Get-Next Request shall be formed, based on the
mapping specified in section 4.
Use of SNMP Get or Get-Next is an implementation issue;
however, SNMP Get-Next is recommended for performance reasons.
Since some non-conforming agents may not implement all the
object types in an object group, SNMPv1 Get would return a
noSuchName error in this case, and the proxy will need to
remove the non-implemented variable binding and resend the SNMP
Request. If SNMP Get-Next is used instead, the proxy would
either discard the non-implemented attribute or translate the
SNMP Response to appropriate CMIS getListError.
If the NAME BINDING used by the object instance defines the
object as deletable, the proxy shall include the DELETEATT
(specified in the NAME BINDING template scannable behavior) in
the requested variable binding list.
If the response for this variable binding is either the same as
the DELETEVALUE specified in the NAME BINDING template
scannable behavior, or SNMPV2ROWSTATUS "notReady", this object
instance shall be treated as if the object instance does not
exist.
3.5.2 Form The Response(s)
The proxy shall form the CMIS response according to the
mappings specified in section 4.
If the CMIS request's attributeIdList is omitted (selects all
attributes), the proxy shall supply all the attributes that are
Chang Expires February 5, 1994 Page 25
Draft ISO/CCITT to Internet Management Proxy 8/5/93
inherited from the ISO/CCITT Top object in the CMIS response.
The proxy shall also retrieve all attributes that are
implemented by the Internet agent. If the Internet agent does
not implement all the variables in an object (which violates
conformance to the SNMP specification), the proxy shall form
the CMIS GetListError response.
3.6 M-CANCEL-GET Service
The M-CANCEL-GET operation shall be performed as described in
[ISO9596-1]. The ISO/Internet proxy does not need to generate
any SNMP Requests in order to emulate the CMIS M-CANCEL-GET
request. However, upon receiving an M-CANCEL-GET request, the
ISO/Internet proxy shall stop sending further CMIS M-GET
responses to the ISO/CCITT manager for the canceled M-GET
request. Furthermore, the proxy shall not initiate further SNMP
Requests to the Internet agent for the canceled M-GET request.
If the Internet agent continues to return SNMP Get responses
corresponding to the canceled M-GET request, they shall be
discarded by the proxy.
Depending on when an M-CANCEL-GET request is received, the
proxy may send out different responses for the canceled M-GET
request and for the M-CANCEL-GET request.
If the Invoke Id of the M-GET request to be canceled is not
recognized by the proxy, the proxy shall return a "no such
invoke identifier" CMIS error to the ISO/CCITT manager. This
can happen when the proxy has not received such an M-GET
request, or when the proxy has completed the identified M-GET
request.
An M-GET operation is considered completed if the corresponding
M-GET response has been sent. For the single object M-GET case,
this means the sending of a single M-GET response. For the
scoped multiple object case, this means the sending of the
final empty M-GET response for the linked replies.
If the identified M-GET request was received, but has not been
completed, the proxy generates an "operation canceled error" to
the ISO/CCITT manager as a response to the canceled M-GET
request. In this case, the proxy will also acknowledge the
successful completion of the M-CANCEL-GET request to the
ISO/CCITT manager.
3.7 M-SET Service
The following sections describe how M-SET service may be
emulated. Upon receiving a CMIS M-SET request, the proxy
verifies the existence of the based managed object, according
to the procedures defined in section 4.1.
3.7.1 Perform The Set Operation
Chang Expires February 5, 1994 Page 26
Draft ISO/CCITT to Internet Management Proxy 8/5/93
For each selected ISO/CCITT object instance, the proxy would
generate one or more SNMP Set Requests to modify the attributes
identified by the CMIS modificationList parameter, according to
the specified modify operator. Only the "replace" modify
operator is supported by the ISO/Internet proxy. The modify
operator is optional and if it is not specified in a CMIS
request, the "replace" operator should be assumed.
The proxy shall check its MIB schema to verify that the
attributes to be modified during emulation of CMIS M-SET
include the REPLACE property.
The CMIS "add value" and "remove value" modify operators are
not supported by SNMP protocol, and are not supported by the
ISO/Internet proxy. Since SNMP uses default values only for
initialization (i.e. at creation time), the "set to default"
modify operator is not supported by the ISO/Internet proxy
either. If the modify operator value included in an M-SET
request is not supported, "invalid operator" should be reported
in the CMIS setListError response.
If the CMIS M-SET request sets the DELETEATT to the DELETEVALUE
(specified in the NAME BINDING template scannable behavior
associated with the object instance), the proxy shall return a
CMIS "invalidOperation" error.
If emulation of the CMIS M-SET request requires generation of a
SNMP Get/Get-Next request and the NAME BINDING associated with
the object instance indicates that the object is deletable,
then the proxy shall include the DELETEATT in the variable
binding list of the SNMP Get/Get-Next request. If DELETEVALUE
or SNMPV2ROWSTATUS "notReady" is returned, the proxy behaves as
though the object instance does not exist.
If the proxy does not need to issue an SNMP Get/Get-Next
request to emulate the CMIS M-SET service, the proxy shall
attempt to perform the request. This is the only case where
an agent which is behaving badly may make an invalid table
entry appear to be instantiated.
3.7.2 Form The Response(s)
If the M-SET request is an "unconfirmed" request, SNMP Get
responses are ignored and no CMIS response shall be returned.
If the M-SET request is a "confirmed" request, the proxy shall
construct an M-SET response. The CMIS M-SET response should
contain the attribute values list or the appropriate
setListError. Once the CMIS M-SET response has been
constructed, it is passed to the CMIP service provider, which
send the corresponding CMIP PDU to the ISO/CCITT manager.
If the CMIS M-SET request is a scoped request, attribute values
of each ISO/CCITT object are reported as a linked reply.
Chang Expires February 5, 1994 Page 27
Draft ISO/CCITT to Internet Management Proxy 8/5/93
3.8 M-ACTION Service
Since Internet MIBs do not have any actions defined, the
translation of CMIS M-ACTION to corresponding SNMP operations
is not needed. Any CMIS M-ACTION request which is received
pertaining to a translated Internet MIB object will be rejected
by the proxy with an "noSuchAction" error response. However,
CMIS M-ACTION may be used by the proxy for other purposes.
3.9 M-CREATE Service
3.9.1 Request Validation
The ISO/Internet proxy is responsible for validating that
incoming CMIS M-CREATE requests do not violate NAME BINDING and
object class definitions.
3.9.2 Name Binding
The ISO/Internet proxy must determine if an instance may be
created according to the CREATE clause of the NAME BINDING
template specified for the object class. If the instance
cannot be created, the CMIS error response
"classInstanceConflict" is returned.
The ISO/Internet proxy must also determine from the NAME
BINDING template if the instance specified in the request may
be created under the superior object instance identified in the
M-CREATE request. If the NAME BINDING does not specify the
identified containment relationship, an "invalidObjectInstance"
CMIS error response should be returned.
3.9.3 Check For Duplication
The proxy must determine if the instance already exists. If it
does, a "duplicate managed object instance" CMIS error response
should be returned.
3.9.4 With Reference Object
If a CMIS M-CREATE request includes a reference object, the
ISO/Internet proxy should retrieve the referenced object
instance from the Internet agent.
The proxy uses an SNMP Get-Next Request for retrieval, with the
parameters translated according to section 4, and with the
<internet instanceId> set to the translated <internet
instanceId> of the reference object for all Internet object
names.
The proxy checks if the attribute used for SNMP row creation
indicates that the row is not available for use (e.g., has been
deleted or is in some other not ready condition). This
Chang Expires February 5, 1994 Page 28
Draft ISO/CCITT to Internet Management Proxy 8/5/93
attribute is the DELETEATT attribute indicated in the scannable
portion of table entries translated according to
[IIMCIMIBTRANS].
If the reference object instance does not exist, the proxy must
send a "No such reference object" CMIS error response to the
ISO/CCITT manager.
3.9.5 With Automatic Instance Naming
A CMIS M-CREATE request can use automatic instance naming to
form a name for the object instance to be created. Automatic
instance naming is used if: a) a CMIS M-CREATE request does not
specify a distinguished name for the object instance to be
created; and b) the request specifies an object class that has
a NAME BINDING allowing automatic instance naming.
It is the responsibility of the ISO/Internet proxy to select an
instance name based on the behavior of the object class and
name binding. In some cases, the relative distinguished name
(RDN) is formed using attributes provided in the CMIS M-CREATE
request. For example, the RDN for the Internet MIB-II "atEntry"
could be formed from the "atNetIfIndex" attribute and the
"atNetAddress" attribute. In other cases, the RDN can be
assigned by the ISO/Internet proxy.
If the superior object instance is not specified, the
ISO/Internet proxy cannot create the object instance and a
"processing failure" CMIS error should be returned.
3.9.6 Perform The Create Operation
The CMIS M-CREATE is realized by setting the status column of
the corresponding Internet MIB table entry to a valid value
with all other columns of the table entry properly initialized.
If the combination of the attributes specified in the CMIS M-
CREATE request and the attributes obtained from the reference
object do not provide a complete set of attribute values for
all of the mandatory attributes for the entry specified by the
object class being instantiated, then the ISO/Internet proxy
should still try to create the object with all the available
attributes.
If SNMPV2ROWSTATUS appears in the NAME BINDING template
scannable behavior for this object, the following procedures
shall be followed:
- if "active" is specified is the CMIS M-CREATE request,
then the proxy shall set the SNMP rowStatus object to
"createAndGo";
- if "notInService" is specified in the CMIS M-CREATE
request, then the proxy shall set the SNMP rowStatus
object to "createAndWait"; or
Chang Expires February 5, 1994 Page 29
Draft ISO/CCITT to Internet Management Proxy 8/5/93
- in all other cases, the proxy shall set the SNMP rowStatus
object to "createAndGo".
If the actual creation process with the incomplete attribute
list succeeds, the ISO/Internet proxy should retrieve all the
attributes of the newly-created entry, including the attributes
which have values supplied by the Internet agent using default
values. This complete list of attribute values is returned in
the CMIS M-CREATE response.
If the actual creation process with this partial attribute list
fails, the ISO/Internet proxy sends a "missing attribute value"
CMIS error back to the ISO/CCITT manager.
3.9.7 Form The Response
The results from the Internet agent are used by the proxy to
construct a CMIS M-CREATE response, which is then returned to
the ISO/CCITT manager, using the mappings defined by section 4.
3.10 M-DELETE Service
3.10.1 Perform the Delete Operation
For all the selected ISO/CCITT object instances, the following
procedures should be taken.
3.10.2 Name Binding
Determine from the NAME BINDING template if the instance
specified in the request may be deleted. If the NAME BINDING
does not allow the deletion of the identified object, a CMIS
error response is returned.
3.10.3 Perform The Delete Operation
If the object instance identified in the CMIS M-DELETE request
exists, the delete operation is performed.
Object deletion is achievable only if there is a columnar
object representing the status of each conceptual row. Deleting
an object instance is realized by setting the status columnar
object to an invalid value. The value representing "invalid" is
implementation-specific. The proxy therefore needs to be aware
of the "invalid" value and the status columnar object in order
to perform the deletion. The NAME BINDING scannable behavior
associated with the object instance provides this information.
Object deletion is achieved by sending an SNMP Set Request to
the Internet agent to change the DELETEATT value to the
DELETEVALUE (for SNMPv1), or to change the rowStatus value to
"destroy" (for SNMPv2).
Chang Expires February 5, 1994 Page 30
Draft ISO/CCITT to Internet Management Proxy 8/5/93
3.10.4 Form The Response(s)
This process includes formatting the CMIP M-DELETE response.
Once the CMIS M-DELETE response has been constructed, it is
returned to the ISO/CCITT manager.
3.11 Management Notification Services
Although SNMPv1 and SNMPv2 use different PDU structures to
convey Traps, all SNMP Traps are mapped to the IIMC-defined
internetAlarm notification and sent as CMIS M-EVENT-REPORTs.
Since SNMP Traps are not confirmed, the translated CMIS M-
EVENT-REPORTs are sent as "unconfirmed" event reports.
If the SNMPv2 manager-to-manager communication is supported
between an Internet manager and an ISO/CCITT manager, it is
possible for the proxy to receive an InformRequest from the
Internet system. Like Traps, InformRequests are also mapped to
CMIS M-EVENT-REPORTs. Unlike Traps, the internetAlarm
notifications resulting from InformRequests are sent as
"confirmed" event reports.
If the translation of Traps to notifications fails, no CMIS M-
EVENT-REPORT will be generated and the SNMP Traps are simply
discarded.
The proxy shall expect a CMIS M-EVENT-REPORT response for all
internetAlarm notifications sent in confirmed mode. The CMIS M-
EVENT-REPORT response shall contain an empty event report
argument. Upon receipt of the CMIS M-EVENT-REPORT response,
the proxy shall return an SNMP Response PDU to the Internet
agent that is in accordance with SNMPv2 protocol rules and
contains an error code of "noError".
If the translation of an SNMPv2 InformRequest to a CMIS M-
EVENT-REPORT fails, the proxy shall send an SNMP Response to
the originator of the SNMP InformRequest with the error code of
"genErr".
If the proxy cannot determine the Internet agent that initiated
the SNMP Trap, then the CMIS M-EVENT-REPORT shall be sent as if
it originated from the cmipsnmpProxy managed object class. This
can occur when there are multiple agents associated with the
same network address or when the proxy is unable to recognize
the network address. Otherwise, the proxy should always be able
to determine the originator from the network address in the
Trap message and the event will be sent as if it originated
from the MIB-II internetSystem under the remote system.
The proxy shall determine the originator of the SNMP Trap using
the following rules in sequence:
Chang Expires February 5, 1994 Page 31
Draft ISO/CCITT to Internet Management Proxy 8/5/93
- Compare the Trap sender's network address against all the
known proxy agent's network addresses. If a unique SNMP
agent matches this address, the originator of the Trap is
identified.
- If more than one known proxy agent's network address
matches the Trap sender's network address, then the
transport address of all the matched proxy agents shall be
compared against the Trap sender's transport address. If
a unique SNMP agent matches this transport address, the
originator of the SNMP Trap is identified.
- If more than one known proxy agent's network and transport
address matches the Trap sender's addresses, then the
known security parameters associated with the proxy agents
are compared with the values supplied in the SNMP Trap
PDU. For SNMPv1, community strings shall be compared. For
SNMPv2, party ids shall be compared. If a unique match is
found, the originator of the SNMP Trap is identified.
- If the above rules can not produce a unique match, then
the originator of the SNMP Trap cannot be identified.
Refer to section 6 for additional information regarding
discrimination of notifications.
4 Common Procedures For CMISE Service Emulation
The procedures described in this section are used during CMISE
service emulation defined in section 3. These procedures are
collected together here for ease of specification, and to
facilitate common implementation.
4.1 Verifying Existence Of An Object Instance
Since the proxy does not maintain a replicate copy of the MIB
data maintained by the Internet agents, the existence of a
managed object, such as a base managed object specified in an
incoming CMIS request, may need to be verified before further
processing, such as scoping and filtering.
If the base object specified in the request does not exist in
the Internet agent, then the proxy must send a
"NoSuchObjectInstance" CMIS error response back to the
ISO/CCITT manager.
If the base managed object is a pseudo object, the
ISO/Internet proxy tries to determine if there exists a non-
pseudo subordinate object. The base object exists if and only
if there exists a non-pseudo subordinate object.
Chang Expires February 5, 1994 Page 32
Draft ISO/CCITT to Internet Management Proxy 8/5/93
4.2 Translating Timestamps
This document does not specify a standard translation for the
timestamp value in CMIS responses. However, the following
paragraphs describe two potential implementations for this
translation: ISO/Internet proxy's local time, and Internet
agent's local time with fixed unknown delta.
4.2.1 ISO/Internet Proxy's Local Time
The timestamp value in the CMIS response can be set to the time
provided by the ISO/Internet proxy's internal clock when the
final SNMP Response is received to complete processing of a
given CMIS request.
4.2.2 Internet Agent's Local Time
The ISO/Internet proxy can query the Internet agent for
"sysUpTime", in addition to the original SNMP variable binding
list in the first SNMP Request. Using this method, this value
is recorded as the "agent's initial sysUpTime" and the
ISO/Internet proxy's local time is recorded as "initial contact
time".
Each CMIS request is then translated to one or more SNMP
Requests by the ISO/Internet proxy to fulfill the CMIS request.
If the last SNMP Request for the same CMIS request is an SNMP
Get Request, the "sysUpTime" is added into the SNMP variable
binding list. Otherwise, an extra SNMP Get Request is issued
with "sysUpTime" as the only element in the variable binding
list. This new "sysUpTime" is called "agent's current
sysUpTime".
The timestamp in the last CMIS response is then calculated as
follows: initial contact time + (agent's current sysUpTime -
agent's initial sysUpTime).
This approach eliminates the inaccuracy caused by network delay
between the ISO/Internet proxy and Internet agent, and gives
the ISO/CCITT manager a more accurate indication of when the
operation was actually performed by the Internet agent (rather
than the time that the response was processed by the
ISO/Internet proxy).
However, in order to convert the sysUpTime, which is the time
ticks since the system was last re-initialized, to the CMIS
event time, the proxy must be made aware of every
reinitialization of the Internet agents. Although each Internet
agent generates a Trap when it first comes up, there is no
guarantee that the proxy will receive this Trap. Therefore,
this method may also be inaccurate.
4.3 Derivation of SNMP Request Parameters
Chang Expires February 5, 1994 Page 33
Draft ISO/CCITT to Internet Management Proxy 8/5/93
4.3.1 SNMPv2 Party and Context Parameters
The SNMPv2 source/destination party and context parameters
shall be derived from the values in the privileged attribute
certificate (PAC) passed in the access control parameter of the
incoming ACSE or CMIS request.
If no incoming access control parameter is received, the proxy
shall use the default context and parties in the
snmpSecurityParameter object instance contained by the
cmipsnmpProxyAgent. If no default applies, the operation shall
be rejected by the proxy with an access denied error.
4.3.2 SNMPv1 Community String Parameter
The SNMPv1 community string parameter shall be derived from the
value in the privileged attribute certificate(PAC) passed in
the access control parameter of the ACSE or CMIS request.
If no incoming access control parameter is received, the proxy
shall use the default community string in the
snmpSecurityParameter object instance contained by the
cmipsnmpProxyAgent. If no default applies, the operation shall
be rejected by the proxy with an access denied error.
4.3.3 Internet Agent Transport Address
For SNMPv2, the proxy uses the value of the destination party
identifier, derived according to the procedures in 4.3.1, to
look up the transport address in a partyEntry object instance.
For SNMPv1, the Internet agent transport address shall be
derived from the associated transport address in the table of
cmipsnmpProxyAgent entries. The cmipsnmpProxyAgent is the one
which has the same systemId as the attribute value within the
RDN of the system object provided in the AETitle (if local name
is used), or the CMIS managed object instance parameter.
4.3.4 SNMP Variable-Bindings Parameter
The SNMP variable-bindings list parameter contains a sequence
of varBinds, each of which is an (Internet object name, value)
pair.
For CMIS M-CREATE, M-SET, M-DELETE requests, the Internet
object name shall be derived from the DN contained in the CMIP
managed object instance parameter, and the attribute identifier
provided in the CMIS request attributeIdList or attributeList
parameter, using the algorithm defined in [IIMCIMIBTRANS]
clause 2.3.1.
For M-CREATE and M-SET requests, the Internet object value
shall be assigned the attribute value associated with the
attributeId from which the Internet object name was derived.
Chang Expires February 5, 1994 Page 34
Draft ISO/CCITT to Internet Management Proxy 8/5/93
For M-GET requests, it is recommended the Internet object value
is NULL.
For M-DELETE requests, the proxy shall use the delete
information as described in the NAME BINDING template behavior
defined for the object class. Within the BEHAVIOUR text, the
DELETEATT specifies the Internet object name and DELETEVALUE
specifies the Internet object value which signifies row
deletion.
4.4 Derivation Of CMIS Parameters
Given the rules specified in this section, and knowledge of the
IIMC containment hierarchy (name bindings), the ISO/CCITT
{classOID}, {attributeOID}, and distinguished name can be
derived from Internet names and the agent identifier.
The iimcAutoTrans OID is known to the proxy. It is defined
in [IIMCIMIBTRANS].
4.4.1 Attribute Id Parameter
Using knowledge of the Internet name structure, and knowledge
of valid <internetEntityId>(a) values known to the proxy, the
<internetEntityId>(a) and <internet instanceId> may be
extracted from the Internet object name.
The extraction process is not possible if the valid
<internetEntityId>(a) value is not known to the proxy. In that
case ,the translation process cannot be performed.
The ISO/CCITT attribute identifier is formed as:
{iimcAutoTrans <internetEntityId>(a)}
4.4.2 Managed Object Class Parameter
In CMIS response, the managed object class parameter can be
derived from the proxy's retained information.
If actual class is used in the incoming CMIS request, the proxy
must derive the object class parameter from the DN in the
original CMIS request. The proxy shall derive the managed
object class OID from the attribute type OID of the last RDN by
removing the common prefix. If the CMIS request is a scoped
request, the object class shall be derived from the retained
information. If the Distinguished name is an empty set of RDN,
"CCITT Rec. X.660 | ISO/IEC 9834-1 : 1992": root is assumed as
the object class.
4.4.3 Managed Object Instance Parameter
Chang Expires February 5, 1994 Page 35
Draft ISO/CCITT to Internet Management Proxy 8/5/93
The managed object instance value (the base managed object's
DN) is retained by the proxy during processing of the CMIS
request. However, for DNs other than the base managed object
instance, the following steps shall be taken to derive the
subordinate RDNs.
1) The final RDN shall be formed by the proxy using the
instance index portion of the variable binding in the SNMP
response and the NAME BINDING information associated with
the object class definition. Assume that the object class
was able to be determined using the procedures of 4.4.2.
The naming attribute type OID can be obtained directly
form the NAME BINDING definition. If the DN represents a
single instance object, the naming attribute is NULL.
Otherwise, the naming attribute can be formed according to
the naming attribute's syntax definition.
2) The sequence of other RDNs for the DN may be determined as
follows.
Use knowledge of the containment hierarchy defined by name
bindings, and the Internet agent's identifier. The name
binding of the object class may be identified as the one
that contains the object class OID as its final component,
in accordance with the name binding registration
procedures defined in [IIMCIMIBTRANS] clause 2.1.3. Use
the superior/subordinate relationships in the name
bindings to build the DN in reverse, beginning with the
final RDN and ending with the RDN for the ISO/CCITT system
object. For superior classes that can have only a single
instance, the naming attribute OID can be obtained from
the name binding definition and the naming attribute value
is NULL. The agent's identifier is used as that of the
value for the RDN of the ISO/CCITT system object.
One case exists for MIBs derived according to
[IIMCIMIBTRANS] where it is possible for the superior
object class to have multiple instances. This may occur
when the subordinate object class is translated as the
result of an SNMPv2 AUGMENTS clause and the superior
object class is a table entry. In that case, the instance
of the superior object class is identified by the same
instanceId that identifies the subordinate object. The
naming attribute value of this RDN is the same as the
final RDN.
If the Internet agent's address cannot be determined,
then it may not be possible to associate a notification
with a specific agent. This may be a problem if multiple
Internet agents are associated with the same network
address. In such cases, the DN for the cmipsnmpProxy
object instance shall be used as the DN for the object
instance.
Chang Expires February 5, 1994 Page 36
Draft ISO/CCITT to Internet Management Proxy 8/5/93
4.4.4 EventId Parameter
The eventId parameter shall be the OID assigned the
internetAlarm as defined in [IIMCIMIBTRANS].
4.4.5 InternetAlarm ProbableCause Parameter
The internetAlarm notification probableCause parameter shall be
derived as defined in [IIMCIMIBTRANS] clause 3.2.5.
Internet traps/notifications are registered using the OID
corresponding to the value of the Internet snmpTrapOID object
defined in [RFC1450].
For SNMPv1 Trap PDUs, the snmpTrapOID is derived as stated in
the SNMPv1/SNMPv2 Coexistence document [RFC1452] clause 4.1.2
(2). That definition is repeated below:
"... if the value of the generic-trap field is
'enterpriseSpecific' then the value used is the concatenation
of the enterprise field from the trap PDU with additional sub-
identifiers, '0', and the value of the specific-trap field."
For notifications defined according to the SNMPv2 SMI, the
probableCause is determined by either the snmpTrapOID.0 or
snmpEventID.i, which is contained in the second variable
binding of the Trap or InformRequest, respectively.
Only the "globalValue" (i.e., OID form) of the probableCause
syntax shall be used.
4.4.6 InternetAlarm AttributeIdentifier List
The following process shall be followed for each variable in
the variable-bindings, excluding the first two variable-
bindings.
The name portion of the variable binding shall be converted to
an ISO/CCITT attributeId using the procedure specified in
section 4.4.1. The converted ISO/CCITT attributeId shall be
placed in the attributeIdList.
4.4.7 InternetAlarm ObjectInstanceList
The following process shall be followed for each variable in
the variable-bindings, excluding the first two variable-
bindings.
The name portion of the variable binding shall be converted to
an ISO/CCITT object instance name using the procedures
specified in section 4.4.3. The converted ISO/CCITT object
instance name shall be placed in the object instance list.
Chang Expires February 5, 1994 Page 37
Draft ISO/CCITT to Internet Management Proxy 8/5/93
If the proxy cannot determine the object instance name (e.g.,
because the Internet agent's identifier cannot be determined),
then the objectInstanceList parameter shall not be included in
the internetAlarm.
4.4.8 InternetAlarm InternetTrapInfo Parameter
The following process shall be followed for each variable in
the variable-bindings.
The name portion of the variable binding shall be converted to
an ISO/CCITT object instance name using the procedures
specified in section 4.4.3. The converted ISO/CCITT object
instance name shall be placed in the objectInstance field of
the internetTrapInfo parameter.
If the Internet agent's identifier cannot be determined, or
the <internetEntityId>(a) is unknown to the proxy, then the
object instance name cannot be determined and the
objectInstance field shall not be included in the
internetTrapInfo parameter, but shall be included in the
unknownVarBindList parameter.
4.4.9 InternetAlarm UnknownVarBindList Parameter
If the proxy cannot determine the attributeId for a variable
binding (i.e., because the <internetEntityId>(a)portion of the
Internet object name is not known to the proxy), then that
variable binding shall be included in the unknownVarBindList
parameter.
4.4.10 InternetAlarm PerceivedSeverity Parameter
The proxy cannot determine the perceivedSeverity for the
translated SNMP Trap without specific knowledge of the Trap.
Therefore, the proxy always assumes "indeterminate" for all the
CMIS M-EVENT-REPORTs generated as a result of SNMP Traps.
However, a proxy can build in some local knowledge of the SNMP
Traps and assign different perceivedSeverity values based on
its local knowledge. Such local knowledge is not within the
scope of this document.
4.4.11 InternetAlarm TransportDomain Parameter
For SNMPv2 Traps, the transportDomain parameter may be
determined by using the one of the party identifier parameters
associated with the Trap. The partyEntry object identified by
the party identifier contains the partyDomain attribute.
For either SNMPv1, or SNMPv2 Traps, knowledge of the transport
protocol used may be provided to the proxy. Alternatively, if
the transport address can be determined, the proxy can
determine the transport protocol from the format of the
Chang Expires February 5, 1994 Page 38
Draft ISO/CCITT to Internet Management Proxy 8/5/93
address. The proxy may then be able to determine the
appropriate transportDomain value from local knowledge of the
OIDs registered for different transport domains.
4.4.12 InternetAlarm TransportAddress Parameter
See section 4.3.3 for possible ways to determine the transport
address.
4.4.13 InternetAlarm AccessControl Parameter
The access control parameter shall be assigned the community
string or party identifiers associated with the SNMP Trap.
5 Error Message Translation
5.1 Translating SNMP Error Messages
SNMP error responses received by the ISO/Internet proxy are
translated to CMIS error responses and sent back to the
ISO/CCITT manager. The following sections provides a mapping
for SNMP error messages to CMIS error responses.
5.1.1 tooBig
If the SNMP error "tooBig" is received, the ISO/Internet proxy
should try to break the SNMP Request into smaller requests and
resend the requests. If it is not feasible to break the
request to any smaller request, and this error occurs, the CMIS
error response "Complexity limitation" should be returned to
the ISO/CCITT manager.
5.1.2 noSuchName
If the SNMP error "noSuchName" occurs when an attribute is
queried as part of a CMIS Filter evaluation, then the
filterItem will be evaluated as FALSE.
In order to check if an object exists, all the object class's
attributes should be queried until at least one attribute's
existence is verified. If none of the attributes exist, and the
object is the base managed object, then a
"NoSuchObjectInstance" CMIS error response should be returned.
If the object exists and the SNMP "noSuchName" error occurs
when attempting to read or modify an attribute, a CMIS "No Such
Attribute" error response should be returned to the ISO/CCITT
manager.
If the ISO/Internet proxy maintains correct schema information
and the Internet agent is a conforming agent, an Internet
object's attributes should either all exist or none exist. In
order to make the ISO/Internet proxy a practical solution, the
Chang Expires February 5, 1994 Page 39
Draft ISO/CCITT to Internet Management Proxy 8/5/93
preceding error situation is included in order to deal with a
non-conforming Internet agent.
5.1.3 badValue
If the SNMP error "badValue" is returned for an SNMP Get
Request, then a "processing failure" CMIS error response should
be returned to the ISO/CCITT manager. In the ProcessingFailure
parameter of the CMIS error response, the errorId should be
"snmpBadValue", and the errorInfo should be the variable
binding identified by the error-index.
If the badValue error occurs during an SNMP Set Request to
fulfill a CMIS M-DELETE request, a "processing failure" CMIS
error response should be returned. In the ProcessingFailure
parameter, the errorId should be " cannotDelete" and the
errorInfo should be the variable binding that is identified by
the error-index.
5.1.4 readOnly
The proxy should never receive an SNMP readOnly error from an
SNMPv1 agent. If this error is received, a "processing
failure" CMIS error response should be returned to the
ISO/CCITT manager. In the processingFailure parameter, the
errorId should be "snmpReadOnly" and the errorInfo should be
the variable binding that is identified by the error-index.
For SNMPv2, if the SNMP error "readOnly" occurs when checking
for the existence of a base object, a "processingfailure" CMIS
error response should be returned to the ISO/CCITT manager.
In the ProcessingFailure parameter of the CMIS error response,
the errorId should be "snmpReadOnly", and the errorInfo should
be the variable binding identified by the error-index. If the
error occurs when deleting the object, then the deleteErrorInfo
field in the response shall be set to "accessDenied".
5.1.5 genErr
If the SNMP error "genErr" occurs, the "ProcessingFailure" CMIS
error response should be returned to ISO/CCITT manager. If the
entry exists, scoping continues; otherwise, scoping terminates.
In the ProcessingFailure parameter of the CMIS error response,
the errorId should be "snmpGenErr".
There are additional error messages in SNMPv2. Most of the
errors are defined for the Set Request. Since a Set Request may
be originated when processing a CMIP M-SET request, an M-CREATE
request or an M-DELETE request, the proxy must ensure each
error code is translated to the one which is most compatible
with the original CMIS request. In addition, the proxy must
ensure the selected error value is compatible with the use of
other parameters such as scoping, filtering, synchronization
and multiple linked reply.
Chang Expires February 5, 1994 Page 40
Draft ISO/CCITT to Internet Management Proxy 8/5/93
5.1.6 noAccess
This error indicates the variable binding's name specifies a
variable which is not accessible by an SNMP Get or Set Request.
This error should be mapped to the CMIS "invalidOperation"
error.
5.1.7 wrongType
This error indicates the variable binding's value field of an
SNMP Set Request specified a type which is inconsistent with
that required for the variable. This error may be mapped to the
CMIS "invalidAttributeValue" error.
5.1.8 wrongLength
This error indicates the variable binding's value field of an
SNMP Set Request specifies, according to the ASN.1 language, a
length which is inconsistent with that required for the
variable. If the original CMIS request is M-CREATE or M-SET,
the CMIS error "InvalidAttributeValue" shall be returned. If
the original CMIS request is M-DELETE, the CMIS "processing
failure" error shall be returned.
5.1.9 wrongEncoding
This error is used to indicate the variable binding's value
field of an SNMP Set Request contains an ASN.1 encoding which
is inconsistent with that field's ASN.1 tag. This error should
be mapped to the CMIS "processingFailure" error.
5.1.10 wrongValue
This error indicates the variable binding's value field in an
SNMP Set Request specifies a value which could under no
circumstances be assigned to the variable. This error should be
mapped to the CMIS "invalidAttributeValue" error.
5.1.11 noCreation
This error is generated when an SNMP Set Request variable
binding name specified a variable which does not exist and
could not ever be created. This error should be mapped to the
CMIS "invalidObjectInstance" error.
5.1.12 inconsistentValue
This error indicates that an SNMP Set Request variable binding
value field specified a value that could under other
circumstances be assigned to the variable, but is presently
inconsistent. If the SNMP Set Request was generated as a result
of a CMIS M-CREATE or M-SET operation, the error should be
mapped to the CMIS "invalidAttributeValue" error.
Chang Expires February 5, 1994 Page 41
Draft ISO/CCITT to Internet Management Proxy 8/5/93
If the SNMP Set Request was generated as a result of CMIS M-
DELETE operation, the error may be mapped to the CMIS
"processingfailure" error.
5.1.13 resourceUnavailable
This error indicates that the assignment of a value by an SNMP
Set Request requires the allocation of a resource which is
presently unavailable. This error may be mapped to the CMIS
"resourceLimitation" error.
5.1.14 commitFailed
When performing an SNMP Set Request, the Internet agent must
ensure all variable assignments occur atomically. If any of the
assignments fail, an SNMP "commitFailed" error is returned. If
the original CMIS request is a "best effort" request, the proxy
should either retry the failed variable assignments by sending
multiple SNMP Set Requests, or return a CMIS setListError with
a "processingfailure" error.
5.1.15 undoFailed
When performing an SNMP Set Request, the Internet agent must
ensure all variable assignments occur atomically. If any of the
assignments fail, the agent should undo all the assignments. An
SNMP "undoFailed" error is returned when the agent cannot undo
all the assignments. CMIS does not have any error value
equivalent to this. The CMIS "processing failure" error must be
returned.
5.1.16 authorizationError
This error indicates that an SNMP Request has been discarded
because the authorization context used in the request does not
allow the PDU type. This error is mapped to the CMIS
"accessDenied" error.
5.1.17 notWritable
The "notWritable" error is used to indicate that an SNMP Set
Request is trying to modify the value of a variable which is
not modifiable, no matter what new value is specified. This
error shall be mapped to the CMIS "invalidOperation" error.
5.2 CMIS Processing Failure
There are many error scenarios in which the error cannot be
mapped to a specific CMIS error. In these cases, the "processing
failure" CMIS error response should be reported back to the
ISO/CCITT manager. This includes scenarios in which the Internet
agent becomes unreachable during emulation of a CMIS request.
Chang Expires February 5, 1994 Page 42
Draft ISO/CCITT to Internet Management Proxy 8/5/93
In order to provide the ISO/CCITT manager with a better
description of the error, the specificErrorInfo field of the
CMIS ProcessingFailure is used to convey the cause of the
problem. Refer to the IIMC specific error PARAMETER templates
defined in section 7.1.4.
6 ISO/CCITT Systems Management Functions
ISO/CCITT systems management standards include a set of Systems
Management Function specifications. An ISO/Internet proxy may
choose to support some or all of these systems management
functions. This section provides some of the modeling
approaches which may be used in supporting ISO/CCITT systems
management functions.
6.1 Event Report Management Function
The ISO/CCITT Event Report Management Function [ISO10164-5]
defines an Event Forwarding Discriminator (EFD) managed object
which allows an ISO/CCITT manager to control the forwarding and
processing of potential event reports by an ISO/CCITT agent.
The Event Report Management Function maybe supported by an
ISO/Internet proxy to allow the ISO/CCITT manager to control
where and how Internet Traps and Inform Requests may be
forwarded.
Since all Internet Traps and Inform Requests are translated by
the proxy and are forwarded to their destinations by the proxy,
EFD managed objects are best supported by the proxy as local
objects. Upon receiving a CMIS M-CREATE request for an EFD, the
proxy creates the EFD object instance according to the
specified name binding. Once created, the EFD is used by the
proxy to determine which CMIS M-EVENT-REPORTs are to be
forwarded to a particular destination during a specified time
period.
6.2 Log Control Function
The ISO/CCITT Log Control Function [ISO10164-6] defines a Log
managed object which allows control and monitoring of a log and
the retrieval of its log records. If the Log managed object is
supported, Internet Traps and Inform Requests may be logged
according to a predefined criteria.
Since only notifications are logged and these are constructed
by the proxy, the Log managed object can be defined as a local
object of a proxy. Upon receiving a CMIS M-CREATE request for a
Log object, the proxy creates the Log instance according to the
specified name binding. Once created, the Log is used by the
proxy to process the received Traps and Inform Requests (and
local notifications) for logging.
Chang Expires February 5, 1994 Page 43
Draft ISO/CCITT to Internet Management Proxy 8/5/93
An InternetAlarmRecord managed object class is defined in
[IIMCIMIBTRANS].
6.3 Scope of the EFD and Log
EFD and Log objects can be created under either the remote
system or the proxy system objects. EFD and Log object
instance behavior is different depending on its position in the
containment tree.
"containment object"
|
+-remote system
| |- EFD (for remote events)
| |- Log - Log Record (for remote events)
| |
| |_ translated MIB group class subtree(s)
|
+-proxy system -- cmipsnmpProxy -cmipsnmpProxyAgent
|
|- EFD (for proxy events)
|- Log - Log Record (for proxy events)
|
|- EFD (for all events)
|- Log - Log Record (for all events)
EFD and Log objects contained by the remote system object shall
process only those events generated by the objects
known to each Internet agent (i.e., objects contained by the
same remote system object).
EFD and Log objects contained by a proxy system object with the
instance name "ProxyOnly" shall process only those events
emitted from the object instances contained by the proxy
system. Any other EFD or Log object contained by the proxy
system shall apply to any event (including all events generated
by any object). If an EFD or Log is created under the proxy
system using automatic instance naming, the proxy shall choose
a name other than the name "ProxyOnly".
7 ISO/CCITT-Internet Proxy MIB
The ISO/CCITT-Internet Proxy MIB defines a set of objects for
specifying the information that is needed for both community-
based and party-based SNMP management on a per Internet agent
basis. The containment hierarchy and other introductory
information regarding this Proxy MIB can be found in section
2.3.
The GDMO templates and ASN.1 modules are included here in one
section to facilitate automated processing. Comments and
subsection headers are included in the form of ASN.1 comments,
i.e., preceded by "--".
Chang Expires February 5, 1994 Page 44
Draft ISO/CCITT to Internet Management Proxy 8/5/93
This document (IIMCPROXY) is allocated the following
registration identifier for purposes of referencing material
contained herein.
iimcIIMCProxy OBJECT IDENTIFIER ::= {iimcManagementDocMan 3}
7.1 Proxy MIB GDMO Templates
-- 7.1.1 Proxy MIB Managed Object Classes
cmipsnmpProxyAgent MANAGED OBJECT CLASS
DERIVED FROM
"Rec. X.721 | ISO/IEC 10165-2 : 1992":top;
CHARACTERIZED BY
cmipsnmpProxyAgentPkg PACKAGE
BEHAVIOUR cmipsnmpProxyAgentPkgBehaviour
BEHAVIOUR
DEFINED AS
!This managed object class is used to
represent an Internet agent in the
proxy MIB. Each agent that the proxy
manages is represented by an instance
of this object class.
The cmipsnmpProxyAgentId attribute
contains the administratively-
assigned name of the managed system
that contains the Internet agent.
Usually this is an Internet Domain
Name. This attribute value shall be
determined by the manager when the
object is created.
The transportAddress and
transportDomain attributes provide
information used to send SNMP
requests to the Internet agent. The
semantics of these attributes are
defined by [IIMCIMIBTRANS].
The managementProtocol attribute
specifies the Internet management
protocol used by the proxy to manage
devices. It shall be the OID
indicating SNMPv1, SNMPv2, or some
other protocol. This attribute is
assigned a value (an OID) by the
manager that is appropriate for the
Internet agent.
Chang Expires February 5, 1994 Page 45
Draft ISO/CCITT to Internet Management Proxy 8/5/93
The supportedMIBs attribute
identifies the set of GDMO documents
that describe the MIBs that the
Internet agent supports. The
ISO/CCITT manager may add elements to
or remove elements from this
attribute.
The remote system object instance that
represents the Internet agent shall be
created by the proxy automatically when
an instance of the cmipsnmpProxyAgent
class is created. The "OP1 Library Vol.
4":capabilityObject defined by [NMF006]
shall be created if the proxy supports
the capability object.
The accessControlMechanism attribute
indicates whether no access control,
Internet access control as specified in
[RFC1446], or ISO/CCITT access control
as specified in [ISO10164-9] is to be
used. The default is no access control.
The administrativeState of the
cmipsnmpProxyAgent can be locked/unlocked
via management operation. When
administrativeState is locked, any
incoming CMIS requests for this agent
result in a CMIS processingFailure
response (adminStateLocked), and no
notifications are generated with this
cmipsnmpProxyAgent's internetSystem as
the source managed object class.
The communicationAlarm with probableCause
equal to lossOfSignal shall be generated by
the proxy when it fails in communicating with
the agent (for example, when exceeding max
retries for an SNMP message). Optional
notification fields such as additionalText and
additionalInfo can be used to supply useful
details to the manager (an implementation
option).!;;
ATTRIBUTES
cmipsnmpProxyAgentId GET,
{iimcIIMCIMIBTRANS}:transportAddress GET-REPLACE,
{iimcIIMCIMIBTRANS}:transportDomain GET-REPLACE,
managementProtocol REPLACE-WITH-DEFAULT GET,
supportedMIBs GET-REPLACE ADD-REMOVE,
accessControlMechanism
DEFAULT VALUE
IimcProxyASN1.agentOnlyAccessControl
Chang Expires February 5, 1994 Page 46
Draft ISO/CCITT to Internet Management Proxy 8/5/93
GET-REPLACE,
"Rec. X.721 | ISO/IEC 10165-2 : 1992":
administrativeState GET-REPLACE;
NOTIFICATIONS
"Rec. X.721 | ISO/IEC 10165-2 : 1992":
communicationsAlarm;;;
CONDITIONAL PACKAGES
retransmissionPackage
PRESENT IF
!supported by the proxy and requested during creation!,
pollingPackage
PRESENT IF
!supported by the proxy and requested during creation!;
REGISTERED AS { iimcProxyObjectClass 1 };
cmipsnmpProxy MANAGED OBJECT CLASS
DERIVED FROM
"Rec. X.721 | ISO/IEC 10165-2 : 1992":top;
CHARACTERIZED BY
cmipsnmpProxyPkg PACKAGE
BEHAVIOUR
cmipsnmpProxyPkgBehaviour BEHAVIOUR
DEFINED AS
!This managed object class is used to contain
objects that represent an Internet agent in the
proxy MIB.
The internetAlarm shall be emitted by this object
class when the application level source of the SNMP
Trap or Inform Request cannot be determined. The
address field of the internetAlarm shall be set to
the network address associated with the SNMP Trap
or Inform Request.!;;
ATTRIBUTES
cmipsnmpProxyId GET;
NOTIFICATIONS
{iimcIIMCIMIBTRANS}:internetAlarm;;;
CONDITIONAL PACKAGES
retransmissionPackage
PRESENT IF
!supported by the proxy and requested during creation!,
pollingPackage
PRESENT IF
!supported by the proxy and requested during creation!;
REGISTERED AS {iimcProxyObjectClass 2};
Chang Expires February 5, 1994 Page 47
Draft ISO/CCITT to Internet Management Proxy 8/5/93
snmpSecurityParameter MANAGED OBJECT CLASS
DERIVED FROM
"Rec. X.721 | ISO/IEC 10165-2 : 1992" : top;
CHARACTERIZED BY
defaultSecurityParameterPkg PACKAGE
BEHAVIOUR
defaultSecurityParameterPkgBehaviour BEHAVIOUR
DEFINED AS
! This object instance contains the default security
parameter that is used only when such AccessControl
field is not received during association
establishment.!;;
ATTRIBUTES
snmpSecurityParameterId GET,
snmpSecurity GET-REPLACE
ADD-REMOVE ;;;
REGISTERED AS {iimcProxyObjectClass 3};
-- 7.1.2 Proxy MIB Packages
retransmissionPackage PACKAGE
BEHAVIOUR retransmissionPackageBehaviour BEHAVIOUR
DEFINED AS
!This optional package is used to influence proxy
service emulation, as described in section 2.5. Note
that
the timeout is a requested value. The actual timeout
depends on the proxy. Also note that the timeout is NOT
a timeout on CMIS request processing.
This package can optionally be instantiated within the
cmipsnmpProxy and/or cmipsnmpProxyAgent objects. If this
package is instantiated in the cmipsnmpProxy object, then
these attribute values apply by default to all Internet
agents. If this package is instantiated in an individual
cmipsnmpProxyAgent object, then the values specified
there apply to the associated Internet agent, over-riding
any default values specified by the superior
cmipsnmpProxy object.!;;
ATTRIBUTES
snmpMsgRetryLimit GET-REPLACE,
snmpMsgTimeout GET-REPLACE;
REGISTERED AS { iimcProxyPackage 1 };
pollingPackage PACKAGE
BEHAVIOUR pollingPackageBehaviour BEHAVIOUR
DEFINED AS
! This optional package specifies the interval
to be used by the proxy for polling the Internet
Chang Expires February 5, 1994 Page 48
Draft ISO/CCITT to Internet Management Proxy 8/5/93
agent, as described in section 2.5.
This package can optionally be instantiated within the
cmipsnmpProxy and/or cmipsnmpProxyAgent objects. If this
package is instantiated in the cmipsnmpProxy object, then
these attribute values apply by default to all Internet
agents. If this package is instantiated in an individual
cmipsnmpProxyAgent object, then the values specified
there apply to the associated Internet agent, over-riding
any default values specified by the superior
cmipsnmpProxy object.!;;
ATTRIBUTES
pollPeriod GET-REPLACE;
REGISTERED AS { iimcProxyPackage 2 };
-- 7.1.3 Proxy MIB Attributes
accessControlMechanism ATTRIBUTE
WITH ATTRIBUTE SYNTAX
IimcProxyASN1.AccessControlEnforcement;
MATCHES FOR EQUALITY, ORDERING;
BEHAVIOUR accessControlMechanismBehaviour BEHAVIOUR
DEFINED AS
!The accessControlMechanism attribute indicates
which access control is to be applied at the proxy
device. The mechanism may be no access control,
the internet access control as defined in
[RFC1446] or one of the ISO access control
mechanisms as defined in [ISO10164-9].!;;
REGISTERED AS {iimcProxyAttributeID 1 };
cmipsnmpProxyAgentId ATTRIBUTE
WITH ATTRIBUTE SYNTAX
IimcProxyASN1.CmipsnmpProxyAgentId;
MATCHES FOR EQUALITY;
BEHAVIOUR cmipsnmpProxyAgentIdBehaviour BEHAVIOUR
DEFINED AS
!This is the naming attribute for the cmipsnmpProxyAgent
object class. This attribute contains the RDN of the
remote system which represents the proxied device.!;;
REGISTERED AS {iimcProxyAttributeID 2 };
Chang Expires February 5, 1994 Page 49
Draft ISO/CCITT to Internet Management Proxy 8/5/93
cmipsnmpProxyId ATTRIBUTE
WITH ATTRIBUTE SYNTAX
IimcProxyASN1.CmipsnmpProxyId;
MATCHES FOR EQUALITY;
BEHAVIOUR cmipsnmpProxyIdBehaviour BEHAVIOUR
DEFINED AS
!This is the naming attribute for the
cmipsnmpProxy object class.!;;
REGISTERED AS { iimcProxyAttributeID 3 };
managementProtocol ATTRIBUTE
WITH ATTRIBUTE SYNTAX
IimcProxyASN1.ObjectIdentifier;
MATCHES FOR EQUALITY;
BEHAVIOUR managementProtocolBehaviour BEHAVIOUR
DEFINED AS
!This attributes specifies the Internet
management protocol used for proxy to
managed devices. It shall have a value of
either SNMPv1 or SNMPv2.!;;
REGISTERED AS {iimcProxyAttributeID 4 };
pollPeriod ATTRIBUTE
WITH ATTRIBUTE SYNTAX IimcProxyASN1.PollPeriod;
MATCHES FOR EQUALITY, ORDERING;
BEHAVIOUR pollPeriodBehaviour
BEHAVIOUR
DEFINED AS
!When polling is enabled (has a non-zero value), the
proxy issues periodic SNMP Get or Get-Next requests
on the Internet system to verify reachability of the
Internet agent. A value of zero means no polling
shall be used.!;;
REGISTERED AS { iimcProxyAttributeID 5 };
supportedMIBs ATTRIBUTE
WITH ATTRIBUTE SYNTAX
IimcProxyASN1.SupportedMIBs;
MATCHES FOR
EQUALITY, SET-COMPARISON, SET-INTERSECTION;
BEHAVIOUR supportedMIBsBehaviour BEHAVIOUR
DEFINED AS
!This attribute specifies the OIDs of the GDMO
documents that are translated from the Internet MIBs
that the Internet agent supports. This attribute
reflects what the OSI manager requests and the proxy
is capable of supporting. If the OSI manager requests
to add values which are not supported by the proxy,
the M-CREATE or M-SET fails!;;
REGISTERED AS {iimcProxyAttributeID 6};
Chang Expires February 5, 1994 Page 50
Draft ISO/CCITT to Internet Management Proxy 8/5/93
snmpMsgRetryLimit ATTRIBUTE
WITH ATTRIBUTE SYNTAX IimcProxyASN1.RetryLimit;
MATCHES FOR EQUALITY, ORDERING;
BEHAVIOUR snmpMsgRetryLimitBehaviour BEHAVIOUR
DEFINED AS
!If the snmpMsgRetryLimit is set to zero, the
proxy will only send each SNMP request once. If
the snmpMsgRetryLimit is set to one, each SNMP
request may be sent twice at most - once for the
original request and once for the retry
following a timeout. The range of this attribute
is between 0 and 100, where 0 indicates no retry
shall be attempted.!;;
REGISTERED AS { iimcProxyAttributeID 7 };
snmpMsgTimeout ATTRIBUTE
WITH ATTRIBUTE SYNTAX
IimcProxyASN1.TimeoutInterval;
MATCHES FOR EQUALITY, ORDERING;
BEHAVIOUR snmpMsgTimeoutBehaviour BEHAVIOUR
DEFINED AS
!This attribute indicates how many milliseconds the proxy
should wait to receive each SNMP response before "timing
out".!;;
REGISTERED AS { iimcProxyAttributeID 8 };
snmpSecurity ATTRIBUTE
WITH ATTRIBUTE SYNTAX
IimcProxyASN1.SnmpSecurity;
MATCHES FOR EQUALITY, SET-COMPARISON, SET-INTERSECTION;
BEHAVIOUR snmpSecurityBehaviour BEHAVIOUR
DEFINED AS
!This attribute specifies the default values to be used
when other AccessControl values are not available (i.e.,
when no AccessControl fields are received during
association establishment or on a given CMIS
operation).!;;
REGISTERED AS {iimcProxyAttributeID 9 };
snmpSecurityParameterId ATTRIBUTE
WITH ATTRIBUTE SYNTAX
IimcProxyASN1.SnmpSecurityParameterId;
MATCHES FOR EQUALITY;
BEHAVIOUR snmpSecurityParameterIdBehaviour
BEHAVIOUR DEFINED AS
!This is the naming attribute for the
snmpSecurityParameter object class.!;;
REGISTERED AS { iimcProxyAttributeID 10 };
Chang Expires February 5, 1994 Page 51
Draft ISO/CCITT to Internet Management Proxy 8/5/93
-- 7.1.4 Proxy MIB Name Bindings
cmipsnmpProxy-systemNB NAME BINDING
SUBORDINATE OBJECT CLASS cmipsnmpProxy;
NAMED BY SUPERIOR OBJECT CLASS
"Rec. X.721 | ISO/IEC 10165-2 : 1992":system;
WITH ATTRIBUTE cmipsnmpProxyId;
BEHAVIOUR cmipsnmpProxy-systemNBBehaviour BEHAVIOUR
DEFINED AS
!There is only one object instance of this object class in
the proxy and this managed object instance should be
created by the proxy process. It is not creatable and
deletable via CMIP management operation.!;;
REGISTERED AS {iimcProxyNameBinding 1};
cmipsnmpProxyAgent-cmipsnmpProxyNB NAME BINDING
SUBORDINATE OBJECT CLASS cmipsnmpProxyAgent;
NAMED BY SUPERIOR OBJECT CLASS cmipsnmpProxy;
WITH ATTRIBUTE cmipsnmpProxyAgentId;
BEHAVIOUR cmipsnmpProxyAgent-cmipsnmpProxyNBBehaviour
BEHAVIOUR
DEFINED AS
!This managed object may be created and deleted
either by management action, or by local action, of
the proxy.
A side effect of the creation/deletion of this object
shall be the creation/deletion of the ISO system
managed object associated with the Internet agent.
The cmipsnmpProxyAgentId contains the RDN of
the proxied device.!;;
CREATE WITH-REFERENCE-OBJECT;
DELETE;
REGISTERED AS {iimcProxyNameBinding 2};
snmpSecurityParameter-cmipsnmpProxyNB NAME BINDING
SUBORDINATE OBJECT CLASS snmpSecurityParameter;
NAMED BY SUPERIOR OBJECT CLASS cmipsnmpProxy;
WITH ATTRIBUTE snmpSecurityParameterId;
BEHAVIOUR snmpSecurityParameter-cmipsnmpProxyNBBehaviour
BEHAVIOUR
DEFINED AS
!This managed object is created automatically when the
containing cmipsnmpProxy object is created. There is
only one instance of this class per cmipsnmpProxy.!;;
REGISTERED AS {iimcProxyNameBinding 3};
Chang Expires February 5, 1994 Page 52
Draft ISO/CCITT to Internet Management Proxy 8/5/93
-- 7.1.4 Proxy MIB Parameters
adminStateLocked PARAMETER
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX
IimcProxyASN1.MiscellaneousError; BEHAVIOUR
adminStateLockedBehaviour BEHAVIOUR DEFINED AS
!This error is used by the proxy to indicate the
administrativeState of the proxied device is
locked and no more proxy service is provided to
the proxied device.!;;
REGISTERED AS { iimcProxyParameter 1 };
noResponse PARAMETER
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX IimcProxyASN1.VarBindList;
BEHAVIOUR noResponseBehaviour BEHAVIOUR
DEFINED AS
!This error is used by the proxy to indicate it
has not received any SNMP response for an SNMP
request required to emulate a CMIS service.!;;
REGISTERED AS { iimcProxyParameter 2 };
cannotDelete PARAMETER
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX IimcProxyASN1.VarBind;
BEHAVIOUR cannotDeleteBehaviour BEHAVIOUR
DEFINED AS
!The proxy emulates the CMIS M-DELETE service by
issuing an SNMP Set Request on the DELETEATT that is
specified in the NAME BINDING template scannable
behavior for this object. However, if the agent
returns an SNMP badValue error, it means the Internet
agent does not allow deletion of the specified table
entry and this CMIS error shall be returned in
response to the CMIS M-DELETE.!; ;
REGISTERED AS { iimcProxyParameter 3 };
protocolNotImplemented PARAMETER
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX IimcProxyASN1.ProtoNotImplErrorInfo;
BEHAVIOUR protocolNotImplementedBehaviour
BEHAVIOUR DEFINED AS
!If the transport, authentication, or privacy
protocol required is not supported by the
proxy, this CMIS error shall be returned.!;;
REGISTERED AS { iimcProxyParameter 4 };
Chang Expires February 5, 1994 Page 53
Draft ISO/CCITT to Internet Management Proxy 8/5/93
snmpTooBig PARAMETER
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX IimcProxyASN1.VarBindList;
BEHAVIOUR snmpTooBigBehaviour
BEHAVIOUR DEFINED AS
!This error is used by the proxy to indicate that
SNMP variable bindings generated during CMIS
emulation caused the Internet agent to return an SNMP
tooBig error.!;;
REGISTERED AS { iimcProxyParameter 5 };
snmpBadValue PARAMETER
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX IimcProxyASN1.VarBind;
BEHAVIOUR snmpBadValueBehaviour BEHAVIOUR
DEFINED AS
!This error is used by the proxy to indicate that
SNMP variable bindings generated during CMIS
emulation caused the Internet agent to return an SNMP
badValue error.!;;
REGISTERED AS { iimcProxyParameter 6 };
snmpGenErr PARAMETER
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX IimcProxyASN1.MiscellaneousError;
BEHAVIOUR snmpGenErrBehaviour BEHAVIOUR
DEFINED AS
!This error is used by the proxy to indicate that
SNMP variable bindings generated during CMIS
emulation caused the Internet agent to return an SNMP
genError error.!;;
REGISTERED AS { iimcProxyParameter 7 };
wrongLength PARAMETER
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX IimcProxyASN1.VarBind;
BEHAVIOUR wrongLengthBehaviour BEHAVIOUR
DEFINED AS
!This error is used by the proxy to indicate that
SNMP variable bindings generated during CMIS
emulation caused the Internet agent to return an SNMP
wrongLength error.!;;
REGISTERED AS { iimcProxyParameter 8 };
Chang Expires February 5, 1994 Page 54
Draft ISO/CCITT to Internet Management Proxy 8/5/93
wrongEncoding PARAMETER
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX IimcProxyASN1.VarBind;
BEHAVIOUR wrongEncodingBehaviour
BEHAVIOUR DEFINED AS
!This error is used by the proxy to indicate that
SNMP variable bindings generated during CMIS
emulation caused the Internet agent to return an SNMP
wrongEncoding error.!;;
REGISTERED AS { iimcProxyParameter 9 };
7.2 Proxy MIB ASN.1 Module
IimcProxyASN1 {iimcManagementModMan 3}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
iimcManagementProxy, iimcIIMCProxy,
iimcManagementModMan, iimcManagementDocMan,
iimcIIMCIMIBTRANS
FROM IimcAssignedOIDs {iimcManagementModMan 1}
ObjectIdentifier, AccessControlInfo
FROM IimcCommonDef {iimcManagementModMan 2}
MiscellaneousError
FROM Parameter-ASN1Module { joint-iso-ccitt ms(9)
smi(3) part2(2) asn1Module(2) 3 }
VarBind, VarBindList
FROM SNMPv2-PDU
DistinguishedName
FROM InformationFramework { joint-iso-ccitt ds(5)
modules (1) informationFramework (1) };
-- for ISO/CCITT-Internet proxy specific extension
iimcProxySpecificExtension OBJECT IDENTIFIER
::={iimcManagementProxy specificExtension(0)}
-- for ISO/CCITT-Internet proxy object class
iimcProxyObjectClass OBJECT IDENTIFIER
::={iimcManagementProxy managedObjectClass(3)}
-- for ISO/CCITT-Internet proxy package
iimcProxyPackage OBJECT IDENTIFIER
::={iimcManagementProxy package(4)}
-- for ISO/CCITT-Internet proxy parameter
iimcProxyParameter OBJECT IDENTIFIER
::={iimcManagementProxy parameter(5)}
Chang Expires February 5, 1994 Page 55
Draft ISO/CCITT to Internet Management Proxy 8/5/93
-- for ISO/CCITT-Internet proxy name bindings
iimcProxyNameBinding OBJECT IDENTIFIER
::={iimcManagementProxy nameBinding(6)}
-- for ISO/CCITT-Internet proxy attribute
iimcProxyAttributeID OBJECT IDENTIFIER
::={iimcManagementProxy attribute(7)}
-- SNMP Protocol version
iimcSnmpProtocol OBJECT IDENTIFIER
::= { iimcProxySpecificExtension snmpProtocol(1) }
-- the OID for SNMPv1
snmpV1 OBJECT IDENTIFIER ::= {iimcSnmpProtocol snmpV1(1) }
-- the OID for SNMPv2
snmpV2 OBJECT IDENTIFIER ::= {iimcSnmpProtocol snmpV2(2) }
AccessControlEnforcement ::= INTEGER {
agent (0), -- default value
proxy (1),
both (2)}
agentOnlyAccessControl INTEGER ::= 0
CmipsnmpProxyAgentId ::= CHOICE {
name GraphicString,
number INTEGER,
distinguishedName DistinguishedName,
oid OBJECT IDENTIFIER
}
CmipsnmpProxyId ::= NULL
PollPeriod ::= INTEGER(0..MAX) -- seconds
ProtoNotImplErrorInfo ::= INTEGER {
transportProtocol(0),
authenticationProtocol(1),
privacyProtocol(2) }
RetryLimit ::= INTEGER(0..100) -- retries
SnmpOpType ::= BIT STRING {
getReqPdu(0),
getNextReqPdu(1),
getRespPdu(2),
setReqPdu(3),
trapPdu(4),
getBulk(5),
informReq(6) }
Chang Expires February 5, 1994 Page 56
Draft ISO/CCITT to Internet Management Proxy 8/5/93
SnmpSecurity ::= SET OF SEQUENCE {
snmpOperation SnmpOpType,
snmpSecurityInfo AccessControlInfo }
SnmpSecurityParameterId ::= NULL
SupportedMIBs ::= SET OF OBJECT IDENTIFIER
TimeoutInterval ::= INTEGER(1..MAX) -- milliseconds
END
8 Conformance Requirements
8.1 Management Communication Requirements
An implementation of the ISO/Internet proxy shall satisfy the
following management communication requirements.
- The ISO/Internet proxy shall conform to ISO/CCITT CMIP in
the agent role, as specified by [ISO9596-1] and
[ISO9595], and profiled by AOM12 [ISO11183-1,2].
- The ISO/Internet proxy shall conform to either Internet
SNMPv1 or SNMPv2 in the manager role, as specified by
[RFC1157] or [RFC1448].
- The ISO/Internet proxy shall conform to all mandatory
security requirements specified by [IIMCSEC] for each
supported version of SNMP (SNMPv1 and/or SNMPv2). If proxy
supports only SNMPv1, then enforcement of access control
and Party MIB support is optional.
8.2 Management Function Requirements
An implementation of the ISO/Internet proxy shall satisfy the
following management function requirements.
- The ISO/Internet proxy may optionally conform to ISO/CCITT
system management functions in the agent role, as
specified by either [ISO10164-5] or [ISO10164-6], and
profiled by AOM221 [ISO12060-4] or AOM231 [ISO12060-5].
8.3 Management Information Requirements
An implementation of the ISO/Internet proxy shall satisfy the
following management information requirements. For each MIB
identified below, an implementation shall conform to all of the
requirements stated in the corresponding MOCS proforma.
- The ISO/Internet proxy shall support the "system" object
specified by [ISO10165-2], in the agent role.
Chang Expires February 5, 1994 Page 57
Draft ISO/CCITT to Internet Management Proxy 8/5/93
- The ISO/Internet proxy shall support the translated MIB-II
"internetSystem" object specified by [IIMCMIB-II], in the
manager role.
- The ISO/Internet proxy shall support the IIMC Proxy MIB
definitions specified by section 7 of this document, in
the agent role.
- The ISO/Internet proxy shall support the IIMC Party MIB
definitions specified by [IIMCSEC], in the agent role.
- The ISO/Internet proxy shall support the Internet Party
MIB definitions specified by [RFC1447], in the manager
role.
- The ISO/Internet proxy shall support one or more
translated MIBs, derived in accordance with the procedures
specified by [IIMCIMIBTRANS]. For each supported MIB, the
ISO/CCITT GDMO translation shall be supported in the agent
role, and the Internet MIB shall be supported in the
manager role.
- The ISO/Internet proxy shall comply with the information
models specified by [ISO10165-1,4] and either [RFC1155],
[RFC1212], or [RFC1442].
- The ISO/Internet proxy may optionally support the "OP1
Library Vol.4":capabilityObject" specified by [NMF006], in
the agent role.
8.4 Service Emulation Requirements
An ISO/Internet proxy implementation that claims conformance to
this specification must state the level of CMIS service
emulation that it supports. Two levels are defined:
a) a basic proxy which emulates CMIS kernel services, plus
support for scoped CMIS Get and single-assertion filtered
CMIS M-GET on the objectClass attribute; and
b) an enhanced proxy which emulates all CMIS services,
including scoping and filtering on all applicable CMIS
services.
As noted in section 8.1, the proxy requires support for the
Enhanced Management Communications Profile AOM12. That is, the
proxy is required to support CMIP kernel, multiple object
selection, filtering, and multiple reply functional units.
However, a basic proxy is not required to required to carry out
scoping or filtering for CMIS services other than M-GET, or
filtering for CMIS M-GET with complexity greater than a single
attribute value assertion involving the objectClass attribute.
A basic proxy returns the CMIS error "complexity limitation"
for any other CMIS service request which contains a filter
Chang Expires February 5, 1994 Page 58
Draft ISO/CCITT to Internet Management Proxy 8/5/93
parameter or scope parameter value not equal to "base object
alone", and for any CMIS M-GET service request which contains a
filter parameter more complex than the minimal requirement
stated above. These limitations do not apply to the enhanced
proxy, which is required to carry out both scoping and
filtering for all CMIS service requests.
9 Acknowledgments
The following individuals have contributed to this effort.
Bob Aronoff - NIST
Jon Biggar - NetLabs
Mary Brady - NIST
April Chang - NetLabs
Ken Chapman - Stratus Computer Inc.
Alice Chen - Boeing
Christopher Crowell - Cabletron Systems
Jock Embry - Opening Technologies
Ian Emsley - Bull S.A
Paul Golick - IBM
Ulrich Gremmelmaier - University of Stuttgart
Karen Hsing - NIST
Ken Hunter - Hewlett-Packard
Pramod Kalyanasundaram - University of Delaware
John Kimmins - Bellcore
Lee LaBarre - The MITRE Corporation
David Liu - Northern Telecom
Jim MacLeod - U S West
Reece Markowsky - OSIWare
Subrata Mazumdar - IBM
Keith McCloghrie - Hughes LAN Systems
Owen Newnan - U S West
Steve Ng - MPR Teltech
Yasuhiro Ohara - NTT
Jong-Tae Park - KyungPook National University
George Pavlou - University College of London
Lisa Phifer - Bellcore
Jim Reilly - Technical Rsch Ctr of Finland
Tom Rutt - AT&T
Adarsh Sethi - University of Delaware
Raj Sirsikar - University of Delaware
Baltej Singh - OSIWare
Mark Smith - Hewlett-Packard
Einar Stefferud - Network Management Associates
Vinu Sundaresan - Timeplex
Mark Sylor - Digital
Hector Trevino - Bellcore
Huy Truong - Tandem
Al Vincent - U S West
Dean Voiss - NetLabs
David Waitzman - BBN
Graham Wisdom - Timeplex
Yoshi Yamashita - NKK Corporation
Chang Expires February 5, 1994 Page 59
Draft ISO/CCITT to Internet Management Proxy 8/5/93
Mark Zelek - IBM
Chang Expires February 5, 1994 Page 60
Draft ISO/CCITT to Internet Management Proxy 8/5/93
References
[ISO7498-4] ISO/IEC IS 7498-4, Information Processing Systems -
Open Systems Interconnection -Basic Reference Model Part 4 -
Management Framework, 1989.
[ISO8824] ISO/IEC 8824: Information Technology - Open System
Interconnection - Specification of Abstract Syntax Notation One
(ASN.1),1990.
[ISO8825] ISO/IEC 8825: Information Technology - Open System
Interconnection-Specification of Basic Encoding Rules for
Abstract Syntax Notation One (ASN.1),1990.
[ISO9595] ISO/IEC 9595, Information Technology - Open System
Interconnection - Common Management Information Service
Definition, 1991.
[ISO9596-1] ISO/IEC 9596-1, Information Technology - Open
Systems Interconnection - Common Management Information
Protocol - Part 1: Specification, 1991.
[ISO10164-5] ISO/IEC 10164-5: Information Technology - Open
Systems Interconnection - Systems Management - Part 5: Event
Report Management Function, 1991.
[ISO10164-6] ISO/IEC 10164-6: Information Technology - Open
Systems Interconnection - Systems Management - Part 6: Log
Control Function, 1991.
[ISO10164-9] ISO DIS 10164-9, Information Processing Systems -
Open Systems Interconnection - Structure of Management
Information - Part 9: Objects and Attributes for Access
Control, ISO/IEC JTC1/SC21/N7661, March, 1993.
[ISO10165-1] ISO/IEC 10165-1: Information Technology - Open
Systems Interconnection - Structure of Management Information -
Part 1: Management Information Model, 1991.
[ISO10165-2] ISO/IEC 10165-2: Information Technology - Open
Systems Interconnection - Structure of Management Information -
Part 2: Definition of Management Information, 1992.
[ISO10165-4] ISO/IEC 10165-4: Information Technology - Open
Systems Interconnection - Structure of Management Information -
Part 4: Guidelines for the Definition of Managed Objects, 1991.
Chang Expires February 5, 1994 Page 61
Draft ISO/CCITT to Internet Management Proxy 8/5/93
[ISO10165-6] ISO/IEC 10165-6: Information Technology - Open
Systems Interconnection - Structure of Management Information -
Part 6: Requirements and Guidelines for Implementation
Conformance Statement Proformas associated with Management
Information, 1993.
[ISO11183-1] ISO/IEC ISP 11183-1, Information Technology -
International Standardized Profiles AOM1n OSI Management -
Management Communications Protocols - Part 1: Specification of
ACSE, Presentation, and Session Protocols for the use by ROSE
and CMISE, May 1992.
[ISO11183-2] ISO/IEC ISP 11183-2, Information Technology -
International Standardized Profiles AOM1n OSI Management -
Management Communications Protocols - Part 2: AOM12 - Enhanced
Management Communications, June 1992.
[ISO12060-4] ISO/IEC DISP 12060-4, Information Technology -
International Standardized Profiles AOM2n OSI Management -
Management Functions - Part 4: AOM221 - General Event Report
Management, July 1992.
[ISO12060-5] ISO/IEC DISP 12060-5, Information Technology -
International Standardized Profiles AOM2n OSI Management -
Management Functions - Part 5: AOM231 - General Log Control,
July 1992.
[RFC1155] RFC1155, M. Rose and K. McCloghrie, Structure and
Identification of Management Information for TCP/IP based
internets, May 1990.
[RFC1157] RFC1157, J.D. Case, M.S. Fedor, M.L. Schoffstall,C.
Davin, Simple Network Management Protocol (SNMP), May 1990.
[RFC1212] RFC1212, M. Rose, K. McCloghrie - Editors, Concise
MIB Definitions, March 1991.
[RFC1213] RFC1213, K. McCloghrie and M. Rose - Editors,
Management Information Base for Network Management of TCP/IP-
based internets: MIB-II, March 1991.
[RFC1441] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser,
Introduction to version 2 of the Internet-standard Network
Management Framework, April 1993.
[RFC1442] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser,
Structure of Management Information for version 2 of the Simple
Network Management Protocol (SNMPv2), April 1993.
[RFC1446] J.M. Galvin, K. McCloghrie, J.R. Davin, Security
Protocols for version 2 of the Simple Network Management
Protocol (SNMPv2), April 1993.
Chang Expires February 5, 1994 Page 62
Draft ISO/CCITT to Internet Management Proxy 8/5/93
[RFC1447] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Party MIB for version 2 of the Simple Network Management
Protocol (SNMPv2), April 1993.
[RFC1448] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser,
Protocol Operations for version 2 of the Simple Network
Management Protocol (SNMPv2), April 1993.
[RFC1450] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser,
Management Information Base for version 2 of the Simple Network
Management Protocol (SNMPv2), April 1993.
[RFC1452] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser,
Coexistence between version 1 and version 2 of the Internet
Network Management Framework, April 1993.
[IIMCIMIBTRANS] ISO/CCITT and Internet Management Coexistence
(IIMC): Translation of Internet MIBs to ISO/CCITT GDMO MIBs,
Draft 3, August 1993.
[IIMCMIB-II] ISO/CCITT and Internet Management Coexistence
(IIMC): Translation of Internet MIB-II (RFC1213) to ISO/CCITT
GDMO MIB, Draft 3, August 1993.
[IIMCSEC] ISO/CCITT and Internet Management Coexistence (IIMC):
ISO/CCITT to Internet Management Security, Draft 3, August
1993.
[IIMCOMIBTRANS] ISO/CCITT and Internet Management Coexistence
(IIMC): Translation of ISO/CCITT GDMO MIBs to Internet MIBs,
Draft 3, August 1993.
[NMF006] Network Management Forum: Forum 006, OMNIPoint 1
Library Volume 4, Issue 1.0, August, 1992.
[NMFTR107] NM Forum and X/Open, ISO/CCITT and Internet
Management: Coexistence and Interworking Strategy, Issue 1.0,
October, 1992.
Chang Expires February 5, 1994 Page 63
Draft ISO/CCITT to Internet Management Proxy 8/5/93
Appendix A (Normative): Managed Object Conformance Statements
(MOCS)
Editor's Note: [This section will be filled in prior to
publication. When completed, this section will contain a
tabular representation of the managed object classes,
attributes, notifications, and name bindings defined in this
document. The format of these program tables will be as defined
by ISO/IEC 10165-6.]
Chang Expires February 5, 1994 Page 64
Draft ISO/CCITT to Internet Management Proxy 8/5/93
Appendix B (Informative) Example Operation
Operation: CMIS M-GET request
Object class: Internet MIB-II ip
Object instance:{ systemTitle = "NetLabs"/ipId = NULL }
Scope: 1st level down
Filter: ipRouteType == indirect
Attribute id list: ipRouteDest
Example Internet MIB-II ipRouteEntries:
ipRouteDest ipRouteType Other object types
192.95.93.1 direct
192.95.93.2 indirect
192.95.93.3 invalid
192.95.93.4 other
192.95.93.5 indirect
(end of the table)
The following sections show an example of how the
ISO/Internet proxy fulfills the above CMIS M-GET request
based on the example Internet MIB-II ipRouteEntries.
1. Check the existence of the base object
The ISO/Internet proxy issues an SNMP Get-Next Request.
Get-Next Request { ip }
Get Response { ipForwarding = 1 }
If the get is successful, the ISO/Internet proxy will have
verified that the base object exists.
2. Managed object selection
Based on the name binding definition, the following object
classes are found in the "object class group":
a) ipAddrEntry
b) ipRouteEntry
c) ipNetToMediaEntry
For each object in the "object class group", the object
instances may be retrieved via SNMP Get-Next Requests.
a) ipAddrEntry: The definition for this object class
does not contain the attribute specified in the
filter (ipRouteType), therefore the ISO/Internet
proxy concludes that there are no object instances
with ipAddrEntry object class in the scope.
Chang Expires February 5, 1994 Page 65
Draft ISO/CCITT to Internet Management Proxy 8/5/93
b) ipRouteEntry: The definition for this object class
contains the attribute specified in the filter
(ipRouteType),therefore the ISO/Internet proxy
issues SNMP Get-Next Requests to retrieve the object
instances.
The SNMP requests issued and the responses received
would be as follows:
Get-Next Request {ipRouteDest, ipRouteType}
Get Response {ipRouteDest.192.95.93.1 =
192.95.93.1,
ipRouteType.192.95.93.1 = direct}
Get-Next Request {ipRouteDest.192.95.93.1,
ipRouteType.192.95.93.1}
Get Response {ipRouteDest.192.95.93.2 =
192.95.93.2,
ipRouteType.192.95.93.2 =
indirect}
Get-Next Request {ipRouteDest.192.95.93.2,
ipRouteType.192.95.93.2}
Get Response {ipRouteDest.192.95.93.3 =
192.95.93.3,
ipRouteType.192.95.93.3 =
invalid}
Get-Next Request {ipRouteDest.192.95.93.3,
ipRouteType.192.95.93.3}
Get Response {ipRouteDest.192.95.93.4 =
192.95.93.4,
ipRouteType.192.95.93.4 =
other}
Get-Next Request {ipRouteDest.192.95.93.4,
ipRouteType.192.95.93.4}
Get Response {ipRouteDest.192.95.93.5 =
192.95.93.5,
ipRouteType.192.95.93.5 =
indirect}
Get-Next Request {ipRouteDest.192.95.93.5,
ipRouteType.192.95.93.5}
Get Response {ipRouteIfIndex = 5,
ipRouteProto = 1}
c) ipNetToMediaEntry: The definition for this object
class does not contain the attribute specified in
the filter (ipRouteType), therefore the ISO/Internet
proxy concludes that there are no object instances
with ipNetToMediaEntry object class in the scope.
Chang Expires February 5, 1994 Page 66
Draft ISO/CCITT to Internet Management Proxy 8/5/93
There are a set of five object instances in the
scope. After the filter is applied to these five
object instances, there are only two object
instances left on which the CMIS M-GET operation
is performed.
3. Form the response
The following CMIS responses should be formed and sent back
to the ISO/CCITT manager
CMIS M-GET Response (first linked reply PDU):
Object class: ipRouteEntry
Object instance:
{ systemTitle = "NetLabs"/
ipId = NULL/
ipRouteEntryId =
{ ipAddress = "192 95 93 2" }
Attribute list: ipRouteDest = 192.95.93.2
CMIS M-GET Response (second linked reply PDU):
Object class: ipRouteEntry
Object instance:
{ systemTitle = "NetLabs"/
ipId = NULL/
ipRouteEntryId =
{ ipAddress = "192 95 93 5" }
Attribute list: ipRouteDest = 192.95.93.5
CMIS M-GET Response (final empty response PDU)
Chang Expires February 5, 1994 Page 67